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Vorwort des Autors 


Dieses Buch gibt eine Einführung in die Programmierung des 
Macintosh mit Hilfe der Programmiersprache "C". C wurde als 
Grundlage für dieses Buch gewählt, da sich diese Programmier- 
sprache wachsender Popularität erfreut und auf vielen Systemen 
mittlerweile zur Standardprogrammiersprache erhoben worden 
ist. 

Das Buch hat den Anspruch, möglichst schnell und ohne große 
Umwege in die Macintosh-Programmierung einzuweisen. Es ist 
für diejenigen geschrieben, die bereits über Erfahrungen mit der 
Programmierung anderer Systeme verfügen und nun ihre Akti- 
vitäten auf den Macintosh erweitern möchten. Das Buch ist 
praxisorientiert und demonstriert die besprochenen Routinen- 
sammlungen stets an Beispielprogrammen oder Programm- 
fragmenten. Es ist auf die Leser ausgerichtet, die möglichst schnell 
zu konkreten Projekten übergehen möchten, jedoch auf eine solide 
Wissensbasis großen Wert legen. Diese Wissensbasis soll durch 
das Buch vermittelt werden; es enthält sozusagen das "abc" der 
Macintosh-Programmierung, dessen Kenntnis für die ersten ei- 
genen Projekte absolut notwendig ist. Es ist als Einführungswerk 
gedacht, welches den "roten Faden" zur Erstellung einer Macin- 
tosh-Applikation vermittelt. 


Das Buch ist in drei Teile gegliedert: 


Der erste Teil gibt zunächst einen Überblick über die Macintosh- 
Programmierung bzw. über die Macintosh-Systemarchitektur und 
bildet damit die Basis für die nachfolgenden Teile, welche sich 
konkret mit der Programmierung des Macintosh beschäftigen. 


Der zweite Teil ist bereits stark praxisorientiert. In diesem Teil 
werden die Grundlagen der Macintosh-Programmierung vorge- 
stellt. Hier werden die Speicherverwaltung, der Dateizugriff und 


andere wichtige Bausteine eines Macintosh-Programms erläu- 
tert. 


Der dritte Teil des Buches stellt die wichtigsten Routinen- 
sammlungen zur Erstellung einer grafischen Benutzeroberfläche 
vor. Parallel zur Vorstellung dieser Bibliotheken wird schrittweise 
ein Beispielprogramm aufgebaut, welches jeweils die Funktio- 
nalitäten der vorgestellten Bibliotheken integriert und so den 
Praxisbezug herstellt. Die Entwicklung dieser Beispielprogramm- 
Reihe führt schließlich zu einer Rahmenapplikation, welche als 
Basis für Ihre eigenen Projekte verwendet werden kann. Dieses 
Programm enthält alle wichtigen Elemente einer typischen Mac- 
intosh-Applikation (z.B. Verwaltung mehrerer Fenster, Scrollbars, 
Dateizugriff, Dialoge etc.) und bildet eine solide Basis für kom- 
plexe Projekte. 


Ich hoffe, daß dieses Buch Ihnen den Einstieg in die Macintosh- 
Programmierung erheblich erleichtert und daß Sie genauso viel 
Spaß bei der Erkundung der inneren Bereiche des Macintosh bzw. 
der Realisierung eigener Projekte haben, wieich es in den letzten 
Jahren hatte. 


Carsten Brinkschulte, 
Februar 1992 
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Der erste Teil des Buches ist eine Einführung in die Welt der 
Macintosh-Programmierung. Hier wird auf die wichtigsten 
Konzepte des User-Interface-Designs eingegangen, und ein 
Überblick über die Systemarchitektur des Macintosh gegeben. 


Kapitel 1 stellt eine Einführung und Analyse der auf dem Macintosh 
gültigen User-Interface-Standards dar. Dieses Kapitel gibt Hin- 
weise und Regeln zur Implementierung dieser wichtigen Stan- 
dards. Weiterhin gibt es einen Überblick über die speziellen 
Konzepte der Macintosh-Programmierung. 


Kapitel 2 gibt einen Überblick über die Macintosh-Systemar- 
chitektur. Hier wird beschrieben, wie die einzelnen Teile des 
komplexen Betriebssystems zusammenarbeiten und wie ein 
Programm auf diese Teile zugreifen kann. In diesem Kapitel sind 
auch wichtige Hinweise zur Erstellung kompatibler Applikatio- 
nen enthalten. 


Dieses Kapitel beschreibt die wichtigsten Konzepte der Macin- 
tosh-Programmierung. Zunächst werden Richtlinien für die Er- 
stellung der Mensch-Maschine-Schnittstelle gegeben. Die Be- 
nutzeroberfläche ist eines der wichtigsten Elemente des Macin- 
tosh, ihre Erstellung erfordert ein gutes Verständnis der hier 
vorgestellten Konzepte. 

Im zweiten Teil des Kapitels wird die Konzeption eines Macintosh- 
Programms mit Programmiereraugen betrachtet. Der zweite Teil 
zeigt die Unterschiede im Vergleich zur "konventionellen" Pro- 
grammierung auf und stellt die Konzeption eines typischen 
Macintosh-Programms vor. 


Der Macintosh ist mit dem Anspruch angetreten, den Computer 
zum einfach zu bedienenden Werkzeug zu machen und der 
"Versklavung der Benutzer" ein Ende zu bereiten. Bei Apple 
Computer gibt es eine Gruppe von Programmierern, Designern 
und Psychologen, die sich mit der Erstellung und ständigen 
Aktualisierung der sogenannten "Human Interface Guidelines" 
befassen. Diese Richtlinien beinhalten die "Regeln", an die sich 
ein Programmierer halten sollte, wenn er ein echtes Mac-Pro- 
gramm schreiben will. Sie definieren die Standards der Mensch- 
Maschine-Schnittstelle in bezug auf die Gestaltung von Menüs, 


Ein Macintosh- 
Programm muß sich 
unbedingt an die 
gültigen Standards 
halten. Programme, die 
versuchen, ihre eigenen 
Standards durchzuset- 
zen, werden erfahrungs- 
gemäß von der 
Macintosh-Gemein- 
schaft nicht 
angenommen. 





geben Hinweise zum Design der grafischen Benutzeroberfläche 
und legen das Verhalten einer Applikation in Standardsituationen 
fest. Es ist diese Konsistenz des Gesamtsystems, die dem Mac 
den Erfolg brachte, den er heute hat. Die Einheitlichkeit der 
Macintosh-Benutzeroberfläche entstand, weil Macintosh-Pro- 
grammierer die "Human Interface Guidelines" konsequent ein- 
gehalten haben. 

Ein erstaunlicher Effekt dieser Einheitlichkeit ist die negative 
Einstellung von Mac-Benutzern gegenüber Programmen, die sich 
nicht an die gültigen Standards halten. Man könnte dieses Ver- 
halten als "arrogant" bezeichnen, ich halte es jedoch für einen 
recht positiven Effekt, eine Art "natürlicher" Selektion unter den 
Programmen. Nur die Programme, die sich an die Forderungen 
der Benutzer nach einheitlicher Bedienoberfläche anpassen, ha- 
ben eine Chance. So fällt es z.B. einigen CAD-Applikationen, die 
ursprünglich auf Workstations entwickelt wurden und jetzt auf 
den Mac portiert wurden, recht schwer, sich auf dem Macintosh- 
Markt durchzusetzen. Viele dieser Portierungen halten sich nicht 
an die "Human Interface Guidelines", und unterscheiden sich in 
bezug auf die Bedienoberfläche erheblich von Standard-Macin- 
tosh-Programmen. Die meisten Macintosh-Benutzer ziehen es vor, 
mit einem Programm zu arbeiten, welches den gültigen Stan- 
dards entspricht, auch wenn es vielleicht nicht so viel Funktio- 
nalität wie die Portierung eines "professionellen" Programms 
besitzt. 

Hält sich ein Programm an die Richtlinien, so "fühlen sich neue 
Benutzer sofort wohl", und sind eher geneigt, das Produkt zu 
verwenden (und zu kaufen). Die Forderung der Benutzer nach 
Einheitlichkeit wird vielleicht dadurch erklärbar, daß ein durch- 
schnittlicher Mac-Benutzer ca. 4-10 Programme verwendet, um 
seine täglichen Aufgaben zu erledigen. Esist durchaus verständlich, 
daß er wenig Lust verspürt, ständig mit den Handbüchern von 
zehn Programmen zu arbeiten, noch sich jeweils die Eigenheiten 
des einzelnen Programms zu merken. Sind alle Programme ähn- 
lich zu bedienen, so ist der Lernaufwand, der investiert werden 
muß, um eine neues Programm zu benutzen, wesentlich geringer, 
als wenn jedes Programm seine eigene "Philosophie" durchsetzt. 
So ist auf dem Macintosh ein einheitliches, intuitives User-Inter- 
face ohne Modi das erste Ziel. Ein intuitives User-Interface ist 
eine Bedienoberfläche, die es einem Benutzer erlaubt, ohne in 





die Dokumentation zu sehen, mit den meisten Funktionalitäten 
des Programms zu arbeiten. Der Benutzer kann also seine Erfah- 
rungen, die er mit anderen Programmen gemacht hat, direkt auf 
die Anwendung eines neuen Programms übertragen. Erreicht 
werden kann dies einerseits durch die strikte Einhaltung der 
"Human Interface Guidelines", andererseits durch die Verwendung 
von bekannten Strukturen aus Standard-Mac-Programmen sowie 
grafischen Elementen in der Benutzeroberfläche. 








SI BA « 


Subdirectory Printer warning 


Grafische Elemente, die die Funktionalität des Programms steu- 
ern, sollten aus der realen Welt des Benutzers oder der Problem- 
stellung übernommen werden, da nur so die Möglichkeit der 
Assoziation, der intuitiven Benutzung geboten wird. Beispiele 
für solche Elemente lassen sich in nahezu jedem Mac-Programm 
finden. So stellt der Finder des Macs beispielsweise Directories 
mit einem Ordnersymbol dar; ein Lineal zur Formatierung von 
Text wird in MacWrite und anderen Textverarbeitungspro- 
grammen eben auch als ein solches dargestellt. 


Es existieren 5 Gebote, die bei der Programmierung des Macin- 
tosh unbedingt beachtet werden sollten. Diese Gebote stellen grobe 
Richtlinien dar, die Hinweise zur Erstellung benutzerfreundlicher, 
zukunftskompatibler und stabiler Programme geben. 


Ein typisches Macintosh-Programm sollte dem Benutzer unmit- 
telbar das Ergebnis einer Aktion präsentieren. Hat er beispiels- 
weise in einer Textverarbeitung ein Wort selektiert, und wählt 
aus dem "Stil"-Menü den Unterpunkt "Kursiv" aus, so sollte das 


Abb. 1-1 

Grafische Elemente in 
Macintosh- 
Applikationen. 


Responsiveness 
bedeutet, daß das 
Programm unmittelbar 
auf Benutzeraktionen 
reagieren sollte. Der 
Benutzer muß direkt 
nach der Ausführung 
eines Befehls eine 
visuelle Rückmeldung 
bekommen. 


WYSIWIG bedeutet, daß 
die Bildschirm- 
darstellung von Text 
oder Grafik dem 
Ergebnis beim Drucken 
exakt entspricht. 





Programm sofort die Veränderung anzeigen, nämlich das aus- 
gewählte Wort kursiv darstellen. Diese unmittelbare Antwort des 
Programms (response) auf den Befehl des Benutzers erleichtert 
die Benutzung des Programms vergleichbar mit der eines Werk- 


-zeuges. Das Programm wird durch Implementierung des Res- 


ponsiveness-Gebots zu einem leicht zu erlernenden Werkzeug, 
da es in kleinen, einfachen und gut verständlichen Schritten zu 
bedienen ist. Responsiveness ermöglicht auch das "spielerische" 
Erlernen der Funktionalitäten eines Programms, da die Funk- 
tionsabläufe überschaubar bleiben und eine direkte Verknüpfung 
zwischen Aktion und Ergebnis hergestellt wird. Ein Gegenbeispiel 
wäre die Implementierung einer auf dem Mac verpönten "Ab- 
fragekette". Eine Abfragekette bedeutet eine Verkettung moda- 
ler Dialoge, die den Benutzer daran hindert, die Auswirkungen 
der durchgeführten Einstellungen zu sehen bis er die Kette 
durchlaufen hat. Beispiele für solche Abfrageketten lassen sich 
in zahlreichen Programmen finden, die für ältere Betriebssysteme 
konzipiert wurden. In diesen Abfrageketten akkumuliert das 
Programm eine Reihe von Einstellungen, um diese nach Beendi- 
gung der Abfragekette auf die Daten anzuwenden. Diese Ab- 
frageketten haben den eindeutigen Nachteil, daß dem Benutzer 
das Ergebnis seiner Änderungen erst nach Durchlaufen zahlrei- 
cher Dialoge präsentiert wird. Dabei tritt oft ein Verständnis- 
problem auf; hat der Benutzer mehrere Einstellungen auf einmal 
vorgenommen und ist nicht mit dem Ergebnis zufrieden, so kann 
es recht schwierig werden, die fehlerhafte Einstellung zu korri- 
gieren. Das Konzept der Responsiveness sollte immer über dem 
der Abfrageketten stehen, auch wenn solche Abfrageketten in 
einigen Fällen sinnvoll erscheinen. Abfrageketten degradieren 
den Benutzer zu einer Dateneingabe-Maschine für das Programm. 
Sie stellen undurchsichtige, oft weit verzweigte "Höhlensysteme" 
dar, in denen sich ein Benutzer sehr schnell verlaufen kann, und 
deren Komplexität vorher nicht überschaubar ist. Eine menü- 
gesteuerte Macintosh-Applikation präsentiert dem Benutzer zu 
jeder Zeit (und ohne das Handbuch zu Rate zu ziehen) fast die 
gesamte Funktionalität, da bereits das Herunterklappen der Menüs 
die Möglichkeiten des Programms offenbart. 

Zum Thema der Responsiveness gehört auch das Konzept 
WYSIWIG ("What You See Is What You Get"). Die Implementie- 


rung dieses Prinzips ist bei der Erstellung eines echten Macin- 
tosh-Programms unbedingt notwendig. Der Benutzer eines 
Textverarbeitungsprogramms sollte in dem vorangegangenen 
Beispiel den kursiv formatierten Text auch wirklich kursiv 
gezeichnet sehen und sich nicht erst beim Drucken über das Er- 
gebnis wundern. Es ist nicht tragbar, Textin unformatierter Weise 
zu präsentieren, ohne daß der Benutzer die Möglichkeit hat, sich 
sein Ergebnis vor dem Ausdruck anzusehen und eventuelle 
Korrekturen vorzunehmen. Diese Forderung führt dazu, daß es 
auf dem Mac sozusagen "verboten" ist, Text mit Escape-Sequenzen 
oder ähnlichen Steuersequenzen zu formatieren. 


Was sich wie ein Motto aus der französischen Revolution an- 
hört, ist ein weiterer, wesentlicher Teil der "Human Interface 
Guidelines". Die "Freiheit des Benutzers" bedeutet, daß der Be- 
nutzer über den Programmablauf bestimmt, und es demzufolge 
mehrere Wege zum selben Ziel geben muß. Jeder Benutzer hat 
seine eigene Art, eine bestimmte Problemstellung zu lösen. Er 
fühlt sich unwohl, wenn das Programm ihm vorschreibt, in wel- 
cher Reihenfolge er beispielsweise einen Text zu formatieren hat. 
Übertragen auf die oben beschriebene Situation beim Formatie- 
ren von Text bedeutet das, daß die menügesteuerte Textforma- 
tierung dem Benutzer die Wahl läßt, ob er erst die Schriftart auf 
"Helvetica" und dann den Stil auf "Kursiv" setzt oder ob er die 
umgekehrte Reihenfolge vorzieht. Eine Abfragekette zwingt ihn, 
zuerst das eine und dann das andere zu tun. Die Freiheit des 
Benutzers wird von Programmierern oft unwissentlich, und ohne 
böse Absichten beschnitten. Dies geschieht dadurch, daß der 
Programmierer auch immer der erste Benutzer des Programms 
ist, und dieser "Programmierer-Benutzer" höchstwahrscheinlich 
kaum Probleme bei der Benutzung seiner eigenen Applikation 
haben dürfte. Das Erkennen dieses Problems verpflichtet einen 
Mac-Programmierer, schon während der Design-Phase der 
Oberfläche intensiv mit potentiellen Benutzern über das Projekt 
zu sprechen. Bei solchen Vorgesprächen werden oft Schwierig- 
keiten in der Bedienoberfläche des Programms sichtbar, die zu 


Während der Design- 
Phase der Bedienober- 
fläche sollte die 
"Benutzbarkeit" der 
Oberfläche mit Benut- 
zern besprochen 
werden. 

Eine sorgfältige Planung 
bei der Erstellung der 
Oberfläche ist unbedingt 
notwendig. 


Abb. 1-2 

Konsistenz zwischen 
Macintosh- 
Applikationen. 





einem späteren Zeitpunkt kaum noch zu korrigieren sind. Nur 
durch Diskussion mit Benutzern kann vermieden werden, daß 
der Programmierer dem Benutzer seine Denkweise "aufzwingt". 
Eine wichtige Voraussetzung für die Freiheit des Benutzers ist 
die Konzipierung des Programms nach der sogenannten "Event 
Driven Architecture", da sie praktisch automatisch dazu führt, 
daß dem Benutzer mehrere Wege zum gleichen Ziel offenste- 
hen. Das Konzept der "Event-Driven-Architecture", auf dem alle 
Macintosh-Programme aufgebaut sind, wird unter Punkt 1.4 be- 
schrieben. 
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Die Konsistenz der Macintosh-Oberfläche ist (wie bereits be- 
schrieben) äußerst wichtig. Es gibt mehrere Wege, um ein Pro- 
gramm in die auf dem Macintosh bestehende Konsistenz einzu- 
fügen bzw. es an die gültigen Standards anzupassen. 


1. Man kann die Konsistenz durch das Kopieren von bekannten 
User-Interface-Elementen aus Standard-Programmen sowie durch 
die konsequente Einhaltung der "Human Interface Guidelines" 
erreichen. Die Publikation "Macintosh User Interface Guidelines" 
von Apple Computer gibt wertvolle, detaillierte Hinweise zu der 
Konzeption des Macintosh-ÜUser-Interfaces. Sie beinhaltet Richt- 
linien und Beispiele für die Kunst des User-Interface-Designs. 
Ich möchte Ihnen die Lektüre dieses Buches dringend empfehlen, 
wenn Sie den Macintosh noch nicht "in- und auswendig" kennen, 
da für die Erstellung eines User-Interfaces ein hundertprozenti- 
ges Verständnis der Macintosh-Standards Voraussetzung ist. 


2. Ein weiterer Weg zur Konsistenz ist die Benutzung der soge- 
nannten "ToolBox" des Macintosh, eine umfangreiche Routinen- 


sammlung, von der sich weite Teile mit der Generierung von 
User-Interface-Elementen wie Buttons oder Scrollbars etc. be- 
schäftigen. Die Benutzung dieser Standardelemente garantiert, 
daß verschiedene Programme gleichartig zu bedienen sind. Dies 
ist auch nicht verwunderlich, denn die ToolBox-Routinen, die 
von Macintosh-Programmen verwendet werden, erzeugen immer 
dasselbe "Look and Feel". 


Modi sind ein unnatürliches User-Interface. Sie stellen praktisch 
die "Zwangsjacke" eines Benutzers dar, denn sie zwingen ihn, 
die Arbeitsweise des Programms auf seine Denkweise zu über- 
tragen. Sie hindern ihn daran, von einem Programmteil aus die 
Funktionalitäten eines anderen zu benutzen. (Siehe Abb. 1-3 
Struktur eines modalen Programms) 

Wird ein Programm in der Event-Driven-Architecture aufgebaut, 
so ist dies der erste Schritt zur Vermeidung von modalen Struk- 
turen. Ein Problem stellt dieses Gebot jedoch für Portierungen 
von modal strukturierten Programmen dar, da die Umstellung 
auf eine nichtmodale Struktur, die event-getriebene Struktur, er- 
fahrungsgemäß tiefe Eingriffe in das Programm erfordert. 


Ein Programm sollte sprachenunabhängig gehalten werden. Dies 
bedeutet, daß in einem Macintosh-Programm z.B. keine String- 
Konstanten verwendet werden dürfen. Anstelle der String-Kon- 
stanten verwendet man bei der Programmierung des Macintosh 
die sogenannten "Resources" (ein Teil der ToolBox). Das Kon- 
zept der Resources bedeutet eine Trennung von Programmcode 
und dem Text, den das Programm beispielsweise bei Fehlermel- 
dungen ausgibt. Der Vorteil dieser Trennung liegt darin, daß das 
Programm einfacher und besser lokalisiert werden kann (z.B. ins 
Französische). Dies wird insbesondere zum Vorteil, daman durch 
die Verwendung von Resources anstelle von String-Konstanten 
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Abb. 1-3 
Struktur eines modalen 
Programms. 


Mac 128K 


Abb. 1-4 

Der Ur-Mac hatte nur 
128 KB Hauptspeicher, 
ein 400KB Diskettenlauf- 
werk und kein SCSI- 
Interface. 





Abb. 1-5 

Die heutigen Macs 
haben ein NuBus, 
mehrere Monitore, 
SCSI-Anschluß und ein 
1.4 MB Diskettenlauf- 
werk. 


die Lokalisierung von einem spezialisierten Übersetzungsbüro 
erledigen lassen kann. Ein Macintosh-Programm kann (wenn 
ausschließlich Resources anstelle von String-Konstanten verwendet 
wurden) lokalisiert werden, ohne daß es anschließend neu com- 
piliert werden muß. 

Es ist ebenfalls sehr wichtig, Hardware-Abhängigkeiten eines 
Programms zu vermeiden. Dies bedeutet, daß ein Mac-Programm 
niemals die Hardware direkt ansprechen sollte, auch wenn dies 
selbstverständlich möglich ist. Man sollte wenn immer möglich 
auf die umfangreichen ToolBox-Routinen zurückgreifen, um die 
Hardware praktisch indirekt anzusprechen, da so eine Zu- 
kunftskompatibilität gewährleistet ist. Ein Beispiel dafür: Es gibt 
Macintosh-Programme, die 1984 für den ersten Macintosh ge- 
schrieben worden sind und auch heute noch auf den neuesten 
Modellen der Macintosh-Familie problemlos funktionieren und 
auch neue Peripheriegeräte und Hardware-Konzepte unterstüt- 
zen, obwohl deren Programmierer selbstverständlich bei der 
Einführung des Macintosh (1984) nichts über die Einbindung von 
CD-ROMs, SCSI-Bus-Systemen, Ethernet oder NuBus-Videokarten 
in die Macintosh-Linie wissen konnten. Diese Kompatibilität mit 
neuer Hard- und Software wird durch die Benutzung von ToolBox- 
Routinen erreicht, die auf dem Mac128K beispielsweise nur auf 
ein 400KB Diskettenlaufwerk zugreifen konnten, später jedoch 
so modifiziert wurden, daß sie auch über den SCSI-Bus z.B. ein 
CD-ROM Laufwerk ansprechen können. Die ToolBox-Routinen 
sind Teil des Macintosh-Betriebssystems, und werden jeweils den 
neuesten Hardware-Entwicklungen angepaßt. Sie befinden sich 
entweder im ROM des Rechners, oder werden beim Systemstart 
in den Speicher geladen. Apple hat im Laufe der Geschichte des 
Macintosh viele ursprüngliche ROM-ToolBox-Routinen durch 
verbesserte oder veränderte Versionen ersetzt. Verwendet ein 
Macintosh-Programm ToolBox-Routinen, so ist die Zukunfts- 
kompatibilität des Programms gesichert, da das Programm 
praktisch automatisch an neue Hardware-Umgebungen (neue 
Rechnergenerationen) angepaßt wird. Diese Zukunftskompati- 
bilität der Macintosh-Software stellt einen Investitionsschutz für 
den Kunden dar, der von Macintosh-Benutzern sehr hoch einge- 
schätzt wird. 





Ein "normales" Programm (z.B. ein MS-DOS Programm) ist stark 
modal aufgebaut, d.h. es besteht aus vielen einzelnen Schleifen, 
in denen Eingaben des Benutzers erwartet werden, um an- 
schließend in tiefere Ebenen des Programms zu verzweigen, die 
wiederum solche "Abfrageschleifen" haben. Es ist dem Benutzer 
nicht möglich, ohne die Dokumentation zu Rate zu ziehen, zu 
erkennen, welche Funktionalität das Programm bietet oder in 
welcher Ebene welche Funktionalität geboten wird. Viele Benutzer 
haben Schwierigkeiten mit dieser klassischen Programmstruktur, 
da sie (vergleiche Abb. 1-3) z.B. von der Edit-Ebene aus nicht 
erkennen können, welche Funktionalitäten die File-Ebene bietet, 
noch wie sie dorthin gelangen. Diese Undurchsichtigkeit der 
Programmstruktur wird verstärkt zu einem Problem, wenn der 
Benutzer viele verschiedene Programme benutzt, insbesondere 
wenn die Menüstruktur der verschiedenen Programme unter- 
schiedlich ist. 


Ein typisches Macintosh-Programm ist in einer nichtmodalen 
Struktur aufgebaut. Es ist nach der sogenannten "Event-Driven- 
Architecture" strukturiert. Events sind Ereignisse, die in be- 
nutzergesteuerte Ereignisse (Mausklicks oder Tastatureingaben) 
und systemgesteuerte Ereignisse wie Update- oder Activate-Events 
unterteilt werden können. "Event Driven" bedeutet, daß das 
Programm auf Ereignisse reagiert. "Event-Driven" bedeutet wei- 
terhin, daß sich das Programm zu jeder Zeit in der Lage befin- 
den muß, sämtliche Arten von Events zu behandeln, was wiede- 
rum eine nichtmodale Programmstrukturierung voraussetzt. 

Um auf die Forderungen der Event-Driven-Architecture einzu- 
gehen, wird das Haupt-Programm eines Macintosh-Programms 
in Form einer Endlosschleife programmiert, in der esaneiner Stelle 
gefragt wird, ob ein Event vorliegt. Liegt ein Event vor, so ent- 
scheidet das Programm, um welche Art von Event es sich han- 
delt, reagiert entsprechend und kehrt wieder in die sogenannte 





Konventionelle Pro- 
gramme sind stark 
modal aufgebaut. Sie 
sind daher oft schwer zu 
bedienen. 


Ein "echtes" Macintosh- 
Programm verzichtet 
auf Modi. 


Abb. 1-6 

Das Programm fragt das 
System in der Main- 
Event-Loop, ob ein 
Event vorliegt. Anschlie- 
Bend verzweigt es in die 
entsprechenden Event- 
Behandlungsroutinen, 
um auf den Event zu 
reagieren. Nachdem das 
Programm auf den 
Event reagiert hat, kehrt 
es sofort wieder in die 
Main-Event-Loop 
zurück, um auf weitere 
Events zu warten. 


"Main-Event-Loop" (die Endlosschleife) zurück. Diese Struktur 
eines Programms ist auf dem Macintosh zwingend notwendig, 
um die Konsistenz und Funktionalität des Gesamtsystems zu 
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Eine Macintosh-Applikation sollte im Idealfall sämtliche Funk- 
tionalitäten des Programms zu jeder Zeit zugänglich machen, es 
sollte (wie beschrieben) auf Modi verzichten. Ein Beispiel: Es sollte 
dem Benutzer auch während der Texteingabe die Möglichkeit 
offenstehen, den Text abzuspeichern, ohne das Programm in einen 
anderen Modus zu versetzen. Diese Forderung läßt sich mit der 
event-getriebenen Struktur und der Verwendung von "Pull-Down"- 
Menüs realisieren. Der Benutzer kann in einer Macintosh-Text- 
verarbeitung während der Texteingabe mit der Maus aus dem 
"Ablage"-Menü den Menüpunkt "Sichern" auswählen und so die 
Änderungen an seinem Text abspeichern. Unmittelbar nach dieser 
Aktion kann er, ohne dem Programm weitere Befehle geben zu 
müssen, mit der Texteingabe fortfahren. 

Das Textverarbeitungsprogramm befindet sich in der Endlos- 
schleife, der sogenannten "Main-Event-Loop" und wartet auf Er- 
eignisse. Im gerade beschriebenen Beispiel bekommt es in dem 
Moment, in dem der Benutzer in die Menüleiste klickt, einen 
MouseDown-Event. Es entscheidet dann anhand der Maus-Klick- 
Koordinaten, daß es sich um einen Klick in die Menüleiste han- 
delt und klappt das entsprechende Pull-Down-Menü herunter. 
Nachdem der Benutzer den Menüpunkt "Sichern" ausgewählt 





hat, speichert das Programm die Daten ab, und begibt sich wie- 
derin die Main-Event-Loop, um auf das nächste Ereignis zu warten. 
Gibt der Benutzer nun mit Hilfe der Tastatur Text ein, so bekommt 
das Programm einen oder mehrere KeyDown-Events und fährt 
mit der Texteingabe fort. 

Es gibt zwei verschiedene Arten von Events; die benutzerge- 
steuerten und die systemgesteuerten Events. Beide werden in 
der Main-Event-Loop empfangen und von dort an die entspre- 
chenden Event-Behandlungsroutinen weitergegeben. 


Diese Events werden vom Betriebssystem an das Programm ge- 
schickt, wenn der Benutzer Eingaben mit der Tastatur oder mit 
der Maus macht. Ein Beispiel für einen benutzergesteuerten Event 
ist der KeyDown-Event. Drückt der Benutzer eine Taste der Ta- 
statur, so schickt das Betriebssystem dem Programm einen 
KeyDown-Event. Dieser enthält dann den ASCII-Code der ge- 
drückten Taste. Diese Art von Events wird auf dem Macintosh 
zur Eingabe von Texten in Textverarbeitungsprogrammen ver- 
wendet. 


Mausklicks bewirken einen MouseDown-Event, wobei das Sy- 
stem die Koordinaten des Mausklicks mit dem Event mitliefert. 
Anhand der Koordinaten der Mouse-Down-Events entscheidet 
das Programm, ob der Benutzer in die Menü-Leiste, oder auf die 
sogenannten "Controls" eines Fensters (z.B. die Scrollbars) ge- 
klickt hat. Eine weitere Möglichkeit besteht darin, daß er Text 
oder Objekte, die in dem Fenster dargestellt werden, selektieren 
möchte. Da nahezu sämtliche Funktionalitäten eines typischen 
Macintosh-Programms mit Hilfe der Maus erreicht werden kön- 
nen, ist der Teil eines Macintosh-Programms, welcher sich mit 
der Behandlung von MouseDown-Events befaßt, einer der auf- 
wendigsten Programmteile. Eine ausgeklügelte und gut struk- 
turierte MouseDown-Event-Behandlungsroutine ist daher von 
äußerster Wichtigkeit. 
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Update-Events 


Abb. 1-7 
Zustandekommen und 
‚Ablauf eines Update- 
Events. 








1.4.2 Systemgesteuerte Events 


Systemgesteuerte Events sind Ereignisse, die das System gene- 
riert, um ein Programm auf bestimmte Veränderungen hinzu- 
weisen. Zu diesen Events zählen z.B. die Update-Events, bei de- 
nen das System dem Programm mitteilt, daß ein bestimmter Be- 
reich eines Fensters neu gezeichnet werden muß. Diese Situa- 
tion kann z.B. eintreten, wenn Fenster, die einander überlappen, 
verschoben werden. Wird das im Vordergrund liegende Fenster 
verschoben, so wird ein bestimmter Teil des im Hintergrund lie- 
genden Fensters freigelegt. Das System bemerkt dies und berechnet 
die freigelegte Fläche des im Hintergrund liegenden Fensters. 
Um das Programm aufzufordern, diesen freigelegten Fensterteil 
neu zu zeichnen, schickt das System einen Update-Event an das 
Programm. In diesem Update-Event beschreibt das System die 
freigelegte Fläche. Das Programm reagiert, indem es die Grafik 
oder den Text, an den freigelegten Stellen neu zeichnet. Das Pro- 
gramm ist also für das Neuzeichnen des Fensterinhaltes verant- 
wortlich ! 


Das Konzept der Update-Events bedeutet für die Strukturierung eines 
Macintosh-Programms, daß es zu jeder Zeit in der Lage sein muß, den 
Inhalt seiner Fenster neu zu zeichnen. 
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Die Abbildung 1-7 veranschaulicht den Prozeß, der zu einem 
Update-Event führt, bzw. die Reaktion des Programms: 

Schritt 1 stellt zwei sich überlagernde Fenster dar. Das "Recht- 
eck"-Fenster verdeckt einen Teil der Grafik aus "Kreis". In Schritt 
2 hat der Benutzer das "Rechteck"-Fenster so verschoben, daß 
ein Teil der vorher verdeckten Kreis-Grafik freigelegt wurde. Das 
System zeichnet den freigelegten Teil zunächst mit weißer Farbe 
(es löscht diesen Teil des Bildschirms). Im dritten Schritt schickt 
dasSystem einen Update-Event an das Programm. Dieser Update- 
Event beschreibt die freigelegte Fläche, die Fläche, die neu ge- 
zeichnet werden muß. Das Macintosh-Programm reagiert in Schritt 
4 auf den Update-Event, indem es die Kreis-Grafik neu zeichnet. 


Im Zusammenhang mit Fenstern können auch die sogenannten 
"Activate-Events" auftreten. Wenn ein im Hintergrund liegendes 
Fenster durch einen Mausklick in das Fenster nach vorn geholt 
wird, so ordnet das System die Fensterhierarchie neu und gene- 
riert einen Activate-Event für das nun im Vordergrund liegende 
Fenster, sowie einen DeActivate-Event für das Fenster, welches 
jetzt im Hintergrund liegt. DeActivate-Events fordern das Pro- 
gramm auf, alles zu tun, um dem Benutzer zu verdeutlichen, 
daß ein Fenster nun nicht mehr aktiv ist, d.h. es sollte z.B. dafür 
sorgen, daß eventuell vorhandene Scrollbars unsichtbar gemacht 
werden und Selektionen aufgehoben werden. Umgekehrt soll ein 
Activate-Event dazu führen, daß das Programm die Scrollbars 
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Abb. 1-8 
Zwei Fenster. 





zeigt und selektierten Text oder Grafik 
kennzeichnet. Dieses Verhalten ist ein 
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erkennen, mit dem er gerade arbeitet. Dies 
wird insbesondere wichtig, wenn der 
Bildschirm mit Fenstern überfüllt ist. Der 
Macintosh ist aufgrund einer Fülle solcher 
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nen als andere grafische Benutzerober- 
flächen. Ein paar Fenster machen eben noch 
keinen Macintosh ! 








Idle-Events 


Zur Kategorie der systemgesteuerten Events gehören auch die 
Null-Events oder auch Idle-Events. Diese Events werden dem 
Programm geschickt, wenn der Benutzer mal wieder "schläft", 
d.h. wenn er weder Tastatureingaben macht, noch die Maustaste 
traktiert und auch sonst keine Events vorliegen. Das Programm 
kann sich bei diesen Idle-Events um Aufgaben kümmern, die 
wiederholt erledigt werden müssen, jedoch nicht von unmittel- 
barer Wichtigkeit sind wie z.B. das Blinken der Einfügemarke, 
oder die Form des Cursors, die bei vielen Programmen von der 
Position der Maus abhängig ist. So hat man typischerweise den 
normalen Pfeil-Cursor, wenn die Maus in der Menüzeile posi- 
tioniert ist. Bewegt man den Cursor über einen Texteingabebereich, 
wird der Cursor zu einem Text-Cursor geändert. 


Macintosh- 
Systemarchitektur 


Dieses Kapitel geht auf dieSystemarchitektur des Macintosh ein. 
Hier wird das Schichtenmodell OASIS vorgestellt, welches die 
Zusammenhänge zwischen Betriebssystem, ToolBox und Pro- 
grammen erläutert. Dieses OASIS-Modell wird im Verlauf des 
Kapitels etwas verfeinert, um einen genaueren Einblick in die 
Konzeption des Macintosh-Gesamtsystems zu geben. 

Im zweiten Teil des Kapitels wird die Konzeption des Coopera- 
tive-Multitaskings, die auf dem Macintosh das Zusammenspiel 
der verschiendenen Prozesse regelt, vorgestellt. 


) ry c 2 < ic AAnr 1 
2.1 Das OASIS-Modell 


Das OASIS-Modell ist eines der wichtigsten Konzepte des Mac- 
intosh-Gesamtsystems, welches aus mehreren Teilen besteht. 
OASIS bedeutet "Open Architecture System Integration Strate- 
gy" und ist ein klar untergliedertes Schichtenmodell, in dem jede 
Schicht über definierte Schnittstellen zur nächsten verfügt. 

Das OASIS-Schichtenmodell beschreibt die Strukturierung des 
Gesamtsystems, also das Zusammenspiel zwischen Programm, 
Benutzeroberfläche, ToolBox, Betriebssystem und Hardware. 
Dieses Modell wurde von Apple geschaffen, um die Konzeption 
bzw. die Vorteile, die aus dieser Konzeption erwachsen, zu ver- 
deutlichen. Weiterhin hat dieses Modell die Aufgabe, Program- 
mierer durch ein besseres Verständnis der Gesamt-Konzeption 
die Erstellung zukunftskompatibler Programme zu erleichtern. 
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Abb. 2-1 

Das OASIS-Modell 
untergliedert das 
Gesamtsystem in 
einzelne Schichten. Die 
Anwendungsschicht 
greift stets indirekt über 
die darunterliegenden 
Schichten auf die 
Hardware zu. 





Die folgenden Punkte beschreiben die einzelnen Schichten die- 
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Die Anwendungsebene ist die Ebene, auf der ein Programm ar- 
beitet. Es greift über die verschiedenen Pufferschichten indirekt 
auf die Hardware zu. Ein Macintosh-Programm ist praktisch isoliert 
von der Hardware, es kennt die Hardware-Umgebung, auf der 
es läuft, gar nicht. Ein Macintosh-Programm benutzt stets Routi- 
nen aus den oberen Ebenen, um auf den Bildschirm zu zeichnen, 
Eingaben des Benutzers abzufragen, oder auf das Dateisystem 
zuzugreifen. Die Verwendung der vordefinierten, standardisierten 
Routinen hat mehrere, offensichtliche Vorteile: 


1. Die von Apple vordefinierten Routinen nehmen dem Pro- 
grammierer sehr viel Arbeit bei der Erzeugung der grafischen 
Benutzeroberfläche ab. 

Es existieren beispielsweise Routinen zur Implementierung und 
Verwaltung der Menüleiste, zur Generierung von Fenstern oder 
für die Verwaltung einfacher Texteingabefelder. Diese Routinen, 
die sonst nur mühsam zu implementieren wären, sind von Apple 
vordefiniert und befinden sich entweder im ROM des Compu- 
ters, oder werden zur Systemstartzeit in den Speicher geladen. 


2. Die Verwendung dieser standardisierten Routinen sichert ein 
einheitliches Verhalten aller Programme, die diese Routinen be- 
nutzen. 

Da alle Macintosh-Programme dieselbe Routine benutzen, ver- 
hält sich z.B. ein Texteingabefeld in Programm A genauso wie 
das Eingabefeld von Programm B. Diese Vereinheitlichung bildet 
eine wichtige Säule für die Konsistenz der Benutzerschnittstelle. 


3. Die Verwendung dieser Routinen sichert die Zukunftskom- 
patibilität des Anwendungsprogramms. 

Apple investiert viel in die Weiterentwicklung und Aktualisie- 
rung dieser Routinen, beläßt die Schnittstelle zu diesen Routi- 
nen jedoch in einer konstanten Form. Werden die Routinen be- 
nutzt, so profitiert ein Programm automatisch von einem 
Betriebssystem-Update, in dem sich verbesserte oder veränder- 
te Versionen dieser Routinen befinden. Entwickelt Apple einen 
neuen Macintosh (dies kommt recht häufig vor) so läuft das 
Programm mit größter Wahrscheinlichkeit auch auf diesem neuen 
Gerät, da die Routinen im ROM des neuen Macintosh an die ver- 
änderte Hardware-Umgebung angepaßt wurden. Diese Zu- 
kunftskompatibilität mit neuer Hardware geht noch einen Schritt 
weiter: Werden beispielsweise neue Peripheriegeräte an den 
Macintosh angebunden, so geschieht dies, indem auf unterster 
Betriebssystemebene ein Treiber installiert wird. Handelt es sich 
bei diesem Peripheriegerät z.B. um ein magneto-optisches Spei- 
chermedium, so können alle Anwendungsprogramme sofort auf 
dieses neue Medium schreiben. Die Programme greifen über den 
File-Manager (einem Teil des Betriebssystems) indirekt auf den 
Treiber für das magneto-optische- Laufwerk zu, die Schnittstelle 
Programm + File-Manager bleibt dieselbe. Das Programm merkt 
also gar nicht, daß es seine Daten auf einem neuen Medium ab- 
legt. 


Die Ebene der Benutzeroberfläche beinhaltet hochintegrierte 
Routinen, die bereits eine komplette, eigene Benutzeroberfläche 
besitzen. Werden Routinen aus dieser Ebene aufgerufen, so 





Das OASIS-Schichten- 
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ware, da die Programme 
niemals direkt auf die 
Hardware zugreifen. 





Systemarchitektur 


Abb. 2-2 

Die Standard- 
Farbauswahl ist ein 
typisches Element der 
Ebene "Benutzerober- 
fläche”. 


übernehmen sie vollständig die Kontrolle über den Macintosh. 
Sie stellen praktisch komplette, standardisierte Programmteile 
dar, die von allen Programmen für denselben Zweck eingesetzt 
werden. Die Ebene der Benutzeroberfläche bietet dem Program- 
mierer mit einem einzigen Aufruf Komplettlösungen für be- 
stimmte, häufig auftretende Problemstellungen. So befinden sich 
in dieser Ebene Routinen, die eine standardisierte Eingabe- 
Oberfläche für die Farbauswahl bieten (siehe Abb. 2-1), Kom- 
plettlösungen für die Daten-Fern-Übertragung (DFÜ) imple- 
mentieren oder standardisierte Dialoge, die beim Abspeichern 
einer Datei benötigt werden. 
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Diese Ebene beinhaltet eine große Anzahl von Routinen, die sich 
mit den verschiedensten Aufgaben beschäftigen. Die Routinen 
sind jeweils in Routinensammlungen, den sogenannten "Mana- 
gern" unter einem Themengebiet zusammengefaßt. Die ToolBox 
stellt den "Werkzeugkoffer" des Programmierers dar. Sie bietet 
keine Komplettlösungen (wie die Benutzeroberfläche), sondern 
stellt nach dem Baukastenprinzip flexibel einsetzbare Bausteine 
für die Implementierung einer grafischen Benutzeroberfläche zur 
Verfügung. Unter diesen Bausteinen befinden sich Routinen- 
sammlungen zur Implementierung von Fenstern, Menüs, Dialo- 
gen, Buttons, Scrollbars etc. Der Einsatz dieser Routinensamm- 
lungen stellt die Hauptaufgabe eines Macintosh-Programmierers 
dar. Im Gegensatz zur "klassischen" Programmierung mit Text- 


Oberfläche beschäftigt sich ein Macintosh-Programmierer ca. 50- 
70 Prozent seiner Arbeitszeit mit der Aneinanderreihung von 
Aufrufen der unzähligen ToolBox-Routinen. 


Diese Ebene beinhaltet das Grundgerüst des Macintosh. Hier 
befinden sich Routinensammlungen für die Speicherverwaltung, 
Dateizugriff und die Netzkommunikation. In dieser Ebene liegen 
auch die Treiber, die die Hardware-abhängige Kommunikation 
mit den Peripheriegeräten übernehmen. Die Betriebssystemebene 
stellt die letzte "Pufferschicht" zwischen Programm und Hardware 
dar. Die Routinen in dieser Ebene werden (abgesehen von der 
Speicherverwaltung) nur von wenigen Programmteilen benutzt, 
da sie sozusagen eine Ebene zu tief sind. Statt die "Low-Level"- 
Routinen des Betriebssystems zu verwenden, sollte ein Zugriff 
auf die höher integrierten (und einfacher zu benutzenden) ToolBox- 
Routinen vorgezogen werden. 


Das OASIS-Schichtenmodell des Gesamtsystems, bzw. die defi- 
nierten Schnittstellen von einer Schicht zur nächsten erlaubt es 
Apple, nachträglich Änderungen im System vorzunehmen, ohne 
dabei die Kompatibilität zu bestehender Anwendungssoftware 
zu verlieren. Diese "Rückwärtskompatibilität" sichert Investitionen 
der Benutzer in Hard- und Software, da auch alte Software noch 
weitestgehend auf neue Betriebssysteme und Hardware-Archi- 
tekturen übernommen werden kann, ohne (wie bei anderen 
Betriebssystemen üblich) jedesmal einen Update bezahlen zu 
müssen. 

Woher kommt nun diese Kompatibilität ? Sie basiert im wesent- 
lichen auf der Schnittstellenarchitektur im OASIS-Modell und 
der Trennung von Programmen und Bibliotheken. Die ToolBox- 
Ebene ist im Prinzip eine "shared" Library, eine umfangreiche 
Routinensammlung, auf die alle Macintosh-Programme zurück- 
greifen, wenn sie beispielsweise ein Menü oder einen Button 
darstellen wollen oder in eine Textdatei schreiben möchten. Diese 
ToolBox-Routinen greifen dann über das Betriebssystem oder über 





installierte Treiber auf die Hardware zu, um die Aufgabe zu er- 
ledigen. 

Legt ein Anwendungsprogramm eine Datei an, so ist es dem 
Programm dabei egal, ob die Datei letztendlich auf einer Disket- 
te, oder über das Netz hinweg auf einem File-Server angelegt 
wird; die ToolBox-Routine und die Parameter, die an sieübergeben 
werden müssen, bleiben dieselben. Das Programm "merkt" also 
gar nicht, auf welchem Medium die Datei anlegt wird. Durch 
diese Struktur wird es möglich, die gesamte Software-Bibliothek 
über Jahre hinweg jeweils mit der neuesten Hardware einzusetzen. 
Funktionieren kann all dies allerdings nur, wenn die Program- 
mierer sich ein wenig "zusammennehmen", und auch wirklich 
nur die von Apple definierten Schnittstellen und Routinen be- 
nutzen, um auf die Hardware zuzugreifen, wobei die Regel gilt: 


Je höher in der Hierarchie der OASIS - Struktur zugegriffen wird, desto 
höher ist die Zukunftskompatiblilität ! 


Das oben vorgestellte Modell der OASIS-Struktur hat (wie alle 
Modelle) einen Nachteil: Es vermittelt einen etwas verzerrten 
Eindruck der Wirklichkeit. Das vorangegangene Modell hinter- 
läßt den Eindruck, als ob einem Macintosh-Programm nur der 
Weg Benutzeroberfläche> ToolBox— Betriebssystem Hardware 
in der Zugriffshierarchie offenstünde. Das nachfolgende (von mir 
erstellte) Modell der OASIS-Struktur verdeutlicht die verschie- 
denen Möglichkeiten des Zugriffs in die Hierarchie der OASIS- 
Schichten bzw. den hierarchischen Aufbau des Gesamtsystems 
etwas wirklichkeitsgetreuer. Weiterhin ist in diesem Modell 
QuickDraw als eigenständiger Teil aufgeführt, da dieser Teil des 
Gesamtsystems zu komplex und von zu großer Wichtigkeit ist, 
um in der ToolBox-Ebene versteckt zu werden. 
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Diese Darstellung des OASIS-Modells untergliedert das Gesamt- 
system in vier grobe Bereiche: 


1. Die unterste Schicht wird durch die Treiber belegt. Hier befin- 
den sich die Hardware-abhängigen Teile des Gesamtsystems wie 
die Videotreiber, die Treiber für die serielle Schnittstelle oder 
Treiber für SCSI-Geräte wie Festplatten oder CD-ROM-Laufwerke. 
Diese Schicht hat für jede Kategorie von Treibern eine definierte, 
konstante Schnittstelle zur darüberliegenden Betriebssystem- bzw. 
ToolBox-Schicht. Die fest definierte Schnittstelle zu den oberen 
Schichten erlaubt es Drittanbietern, ihre Peripheriegeräte mit 100 
prozentiger Kompatibilität zu sämtlicher Anwendungssoftware 
in das Gesamtsystem einzubinden. Ein Beispiel: Macintosh-Be- 
nutzer kennen keine Kompatibilitätsprobleme zwischen neuen 
Videokarten und Anwendungssoftware, wie dies von MS-DOS 
bekannt ist. Da ein Macintosh-Programm immer über QuickDraw 
indirekt mit den Videotreibern bzw. mit der Videokarte kom- 
muniziert, brauchen Macintosh-Programme nicht an neue Vi- 
deokarten angepaßt werden. Dieses Beispiel läßt sich auf nahe- 
zu alle Peripheriegeräte erweitern. 


Abb. 2-3 

Eine etwas differenzier- 
tere Sichtweise des 
OASIS-Modells. 

Dieses Modell stellt die 
verschiedenen Zugriffs- 
möglichkeiten in die 
Schichtstruktur des 
OASIS-Modells 
eindeutiger dar. 








Die Treiberschicht garantiert die homogene Einbindung neuer Peri- 
pheriegeräte. 


2. Das reine Betriebssystem bildet eine der beiden Basis-Schich- 
ten; d.h. die Speicherverwaltung und das Dateisystem. 

Diese Schicht stellt (ähnlich dem vorangegangenen Modell) eine 
Low-Level-Ebene dar. Diese Ebene beinhaltet die absolut le- 
benswichtigen Funktionalitäten des Gesamtsystems wie den 
Dateizugriff und die Speicherverwaltung. 


3. Die zweite Basis-Schicht wird durch QuickDraw, das Basis- 
Grafikpaket des Macintosh gebildet. 

QuickDraw ist eine umfangreiche Routinensammlung, die sich 
mit der grafischen Darstellung befaßt. Diese Ebene wird von nahezu 
allen Macintosh-Programmen verwendet, um Informationen 
darzustellen. Mit den Routinen dieser Schicht ist esmöglich, Text, 
Linien, Rechtecke, Polygone und andere grafische Strukturen auf 
den Bildschirm zu zeichnen. Weiterhin bildet diese Schicht die 
Grundlage für viele ToolBox-Routinen. 


Alles was auf dem Bildschirm dargestellt wird, wird mit Hilfe von 
QuickDraw-Routinen gezeichnet. 


4. Die ToolBox, die den größten Teil des Gesamtsystems einnimmt, 
und beispielsweise für die Verwaltung und Darstellung von Menüs, 
Fenstern, Dialogen, Buttons oder Scrollbars zuständig ist, bildet 
die am höchsten integrierte Schicht des Gesamt-Systems. Diese 
Ebene enthält den Baukasten, aus dem Macintosh-Applikationen 
aufgebaut sind. Teile der ToolBox-Routinen greifen über das 
Betriebssystem auf die Hardware zu, diese Teile stellen hochin- 
tegrierte Routinen für den Zugriff auf das Betriebssystem bereit. 
Andere Teile der ToolBox (wie z.B. der Menu- oder der Window- 
Manager) erzeugen Standardelemente einer grafischen Bedien- 
oberfläche, indem sie QuickDraw-Routinen verwenden. 


Jede der einzelnen Schichten ist wiederum untergliedert in die 
sogenannten "Manager"; Sammlungen von Routinen, die sich um 
ein gemeinsames Aufgabenfeld kümmern. So gibt es beispiels- 
weise in der ToolBox-Ebene den Menu-Manager, der für die 


Verwaltung und die Darstellung von Menüs zuständig ist. In 
der Betriebssystemebene befindet sich der Memory-Manager, 
welcher sich um die Speicherverwaltung kümmert. Für ein 
Macintosh-Programm gibt es mehrere Wege, indirekt auf die 
Hardware zuzugreifen: Es kann über ToolBox-Routinen indirekt 


auf QuickDraw zugreifen (z.B. beim Zeichnen von Menüs), wel- 


ches dann über einen Videotreiber in die Videokarte schreibt. Es 
kann aber auch direkt mit QuickDraw kommunizieren, um bei- 
spielsweise eine Linie auf dem Bildschirm zu zeichnen. Der Zu- 
griff auf Funktionalitäten des Betriebssystems (z.B. File1/O) kann 
ebenfalls entweder indirekt über die ToolBox oder in direkter 
Kommunikation mit dem Betriebssystem erfolgen. Generell sollte 
man, wie gesagt, direkte Zugriffe auf die Hardware vermeiden, 
und wenn möglich, die höher integrierten High-Level-Routinen 
der ToolBox benutzen. 


Multitasking bedeutet das gleichzeitige Ausführen mehrerer 
Aufgaben oder auch Prozesse auf einem Rechner. Für den Be- 
nutzer besteht Multitasking hauptsächlich darin, daß er bestimmte 
Prozesse im Hintergrund ablaufen lassen kann, während er im 
Vordergrund beispielsweise einen Text eingibt. Solche Hinter- 
grundprozesse können z.B. das Berechnen einer großen, kom- 
plizierten Tabelle, die Abfrage einer Datenbank oder das Abspulen 
eines Druckauftrages sein. 

Es gibt drei verschiedene Arten von-Multitasking: 


1. Preemptive-Multitasking 
2. Cooperative-Multitasking 
3. Interrupt-Multitasking 


Auf dem Macintosh existiert eine Kombination von Cooperati- 
ve- und Interrupt-Multitasking. Diese etwas eigenwillige Art des- 
Multitaskings unterscheidet sich von dem allgemein üblichen 
Preemptive-Multitasking. Apple wurde in der Vergangenheit oft 
kritisiert, da auf dem Macintosh eine eigene Variante des Mul- 
titaskings implementiert wurde. Diese (leider oft recht unsach- 


Auf dem Macintosh ist 
eine Kombination aus 
Cooperative- und 
Interrupt-Multitasking 
implementiert. 





Das Preemptive- 
Multitasking verwendet 
das Zeitscheiben- 
verfahren, um die 
Prozessorzeit auf die 
verschiedenen Prozesse 
zu verteilen. Bei diesem 
Verfahren bekommt 
jeder Prozeß eine feste 
Anzahl an Prozessor- 
Zyklen zugeteilt. Ist die 
Zeitscheibe eines 
Prozesses abgelaufen, 
so wird der Prozeß 
unterbrochen und ein 
anderer abgearbeitet. 


lich geführte) Diskussion möchte ich durch eine Gegenüberstel- 
lung der verschiedenen Arten des Multitaskings etwas versach- 
lichen. 


Diese Variante des Multitaskings ist weit verbreitet, man bezeichnet 
sie auch als "echtes" Multitasking. Sie findet ihren Ursprung im 
UNIX-Betriebssystem bzw. in der Großrechnerarchitektur. Bei 
dieser Art des Multitaskings werden die verschiedenen Prozes- 
se im Zeitscheibenverfahren abgearbeitet. Das Zeitscheiben- 
verfahren bedeutet, daß einem Prozeß (z.B. einem Textverarbei- 
tungsprogramm) 30 Prozent der gesamten Rechenzeit zur Ver- 
fügung gestellt wird. Der Rechner arbeitet eine gewisse Zeit diesen 
Prozeß ab, und unterbricht ihn, wenn die Zeitscheibe zu Ende 
ist. Die Unterbrechung des laufenden Prozesses geschieht auf 
unterster Ebene, sozusagen auf Hardware-Ebene mit Hilfe von 
Interrupts. Daher hat der unterbrochene Prozeß keinerlei Mög- 
lichkeiten, die Unterbrechung aufzuhalten, das Betriebssystem 
sorgt für eine gleichmäßige Bearbeitung aller konkurrierenden 
Prozesse. Historisch gesehen kommt diese Art von Multitasking 
(wie gesagt) von Multi-User-Betriebssystemen wie UNIX. Hier 
übernimmt das Preemptive-Multitasking die Aufgabe, mehre- 
ren, gleichzeitig an einem Rechner arbeitenden Benutzern ent- 
sprechend ihrer Privilegien Rechenzeit zuzuteilen. So ist es an 
Universitäten oft der Fall, daß ein kleiner Student sich mit weni- 
gen Prozenten der Rechenzeit zufrieden geben muß, wenn ein 
Professor (natürlich mit höherer Priorität) gleichzeitig mit ihm 
an dem selben Rechner arbeitet. Preemptive-Multitasking bedeutet 
praktisch eine Zerteilung eines Rechners in beliebig viele Unter- 
rechner. Die Prozesse eines höher eingestuften Benutzers bele- 
genauch dann einen hohen Prozentsatz der Rechenleistung, wenn 
der Benutzer keine Eingaben macht, seine Prozesse sozusagen 
im "Leerlauf" sind. 

Das Verfahren des Preemptive-Multitaskings wird in letzter Zeit 
immer häufiger auf Single-User-Workstations eingesetzt. Hier 
hat es die Aufgabe, im Hintergrund laufende Prozesse mit 
Rechenzeit zu versorgen, während sich der Benutzer z.B. mit ei- 





ner Textverarbeitung beschäftigt. Ein Betriebssystem mit der Fä- 
higkeit zum Preemptive-Multitasking sorgt dafür, daß ein im 
Hintergrund laufender Druckprozeß eine konstante Zeitscheibe 
zugeteilt bekommt, während im Vordergrund andere Prozesse 
abgearbeitet werden. Diese Konzeption vermittelt auf den ersten 
Blick eine faszinierende Möglichkeit, die Leistung eines Compu- 
ters optimal ausnutzen zu können. Dies ist bei textorientierten 
Benutzeroberflächen wie z.B. UNIX auch sicherlich der Fall. Bei 
grafischen Benutzeroberflächen (wie X-Windows) bereitet diese 
Technologie jedoch in dem Moment Schwierigkeiten, wenn die 
Rechenleistung des Computers nicht mehr ausreicht, um alle 
Prozesse mit einer angemessenen Zeitscheibe auszustatten. Lau- 
fen auf einem Preemptive-Multitasking-Computer mehr Prozesse 
ab, als er verkraften kann, so werden die Zeitscheiben aller Pro- 
zesse verkürzt. Beirechenintensiven Prozessen (z.B. Programmen 
mit grafischer Benutzeroberfläche) kann die Konzeption des 
Preemptive-Multitaskings schnell dazu führen, daß die Zeitscheibe 
der Vordergrund-Applikation so kurz wird, daß dem Benutzer 
unangenehme Nebeneffekte auffallen. Diese Nebeneffekte drük- 
ken sich durch ein Springen des Maus-Cursors oder durch die 
verspätete Reaktion auf Mausklicks oder Tastatureingaben aus. 
Die Verspätungen kommen daher, daß das Betriebssystem dem 
Vordergrundprozeß die Kontrolle entzogen hat, um Hinter- 
grundprozessen Zeit zum Arbeiten zu geben. Während die Hin- 
tergrundprozesse abgearbeitet werden, kann das im Vordergrund 
liegende Programm nicht auf Benutzereingaben wie Mausklicks 
oder Tastatureingaben reagieren. Erst wenn es die Kontrolle zu- 
rückbekommt, wird es auf die Benutzereingaben reagieren 
können. Das Problem bei diesem Verhalten des Gesamtsystems 
liegt darin, daß ein Benutzer schnell verwirrt wird, wenn das 
Programm nicht auf seine Eingaben reagiert. Dies führt dann oft 
dazu, daß der Benutzer die Mausklicks wiederholt oder erneut 
die Tastatur betätigt, um seine Eingaben zu wiederholen. Bekommt 
der Vordergrundprozeß dann wieder die Kontrolle, so werden 
alle gespeicherten Eingaben auf einmal abgearbeitet. "Das Pro- 
gramm spielt verrückt!" ist eine häufige Reaktion der Benutzer 
auf dieses Verhalten von Programmen. Selbst geübten Benutzern 
fällt das Arbeiten mit einem überlasteten Preemptive-Multitas- 
king-Computer mit grafischer Bedienoberfläche schwer, insbe- 


Da das Preemptive- 
Multitasking eine starre 
Zeiteinteilung unter den 
verschiedenen Prozes- 
sen vornimmt, birgt es 
das Problem in sich, 
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Überlastung des 
Systems wichtige 
Prozesse zu kurz 
kommen. 





Das Cooperative- 
Multitasking verwendet 
eine variable Unter- 
teilung der Prozessor- 
zeit. Das im Vorder- 
grund laufende 
Programm kann 
bestimmen, wieviel Zeit 
den im Hintergrund 
laufenden Prozessen zur 
Verfügung gestellt 
werden soll. 


sondere, wenn der Maus-Cursor hinter der wirklichen Maus- 
position hinterherspringt. Es ist dann nahezu unmöglich, inner- 
halb einer annehmbaren Zeitspanne den Cursor genau zu posi- 
tionieren, da man immer erst darauf warten muß, bis sich der 
Maus-Cursor beruhigt hat. 


Diese Variante des Multitaskings (die auch auf dem Macintosh 
implementiert ist) beruht auf der Kooperation zwischen den ein- 
zelnen Prozessen, die auf einem Rechner laufen. Das Konzept 
des Cooperative-Multitaskings ist nur für Single-User-Workstations 
tragbar, da es in diesem Konzept keine eindeutige Zeitscheiben- 
unterteilung gibt. Bei dieser Art des Multitaskings hat der Vor- 
dergrundprozeß solange die Kontrolle über den Rechner, bis er 
sie freiwillig abgibt. Der Vordergrundprozeß gibt von Zeit zu 
Zeit die Kontrolle an das Betriebssystem ab, und dieses versorgt 
die im Hintergrund laufenden Prozesse mit Rechenzeit. Dies ge- 
schieht in dem Moment, in dem das Programm in der Main-Event- 
Loop das Betriebssystem nach einen neuen Event fragt. Der Vor- 
dergrundprozeß kann dem Betriebssystem, wenn er die Kontrolle 
abgibt, eine "Wunsch-Hintergrundzeit" mitgeben, mit der fest- 
gelegt wird, wieviel Zeit den im Hintergrund laufenden Prozessen 
zur Verfügung gestellt werden soll. Der Vorteil dieses Konzep- 
tes liegt darin, daß der Vordergrundprozeß anhand der 
Benutzeraktivitäten bestimmen kann, wieviel Zeit den im Hin- 
tergrund arbeitenden Prozessen (z.B. Hintergrunddruck) zur 
Verfügung steht. Während der Benutzer beispielsweise Tasta- 
tureingaben macht, setzt ein im Vordergrund laufendes Text- 
verarbeitungsprogramm die Zeit für die Hintergrundprozesse 
auf ein Minimum zurück, damit es in angemessener Zeit auf die 
Benutzereingaben reagieren kann. Setzt der Benutzer mit den 
Tastatur- oder Maus-Eingaben aus, so erhöht der Vordergrund- 
Prozeß die "Wunsch-Hintergrundzeit" auf ein Maximum, so daß 
z.B. dem Hintergrunddruck 80 Prozent der Rechenleistung zur 
Verfügung steht. Im Allgemeinen entspricht diese Art von 
Multitasking dem, was der Benutzer erwartet: Er kann bestimm- 
te Prozesse im Hintergrund ablaufen lassen (z.B. Drucken oder 


eine Datenbankabfrage), die Vordergrund-Applikation wird je- 
doch nicht "zickig", sie reagiert weiterhin in angenehmer Zeit- 
spanne auf Mausklicks oder Tastatureingaben. 

Der Nachteil dieses Konzeptes liegt darin, daß die Hinter- 
grundprozesse sich an die "Wunsch-Hintergrundzeit" des Vor- 
dergrund-Prozesses halten müssen. Im Gegensatz zum Preemptive- 
Multitasking bietet das Cooperative-Multitasking keine Mög- 
lichkeit einen Prozeß nach einer fest vordefinierten Zeit zu un- 
terbrechen. Der Effekt: Wenn ein im Hintergrund laufender Pro- 
zeß die Kontrolle übernimmt und sich nicht an die vereinbarte 
Zeitspanne hält, so blockiert er den gesamten Rechner solange, 
bis er die Kontrolle wieder abgibt. Bei dieser Art des Multitaskings 
liegt also eine große Verantwortung bei den Programmierern von 
Hintergrundprozessen. Sie müssen sich unbedingt an die vorge- 
gebenen Zeitscheiben halten, sonst unterlaufen sie das Konzept 
der Kooperation. 


Das Interrupt-getriebene Multitasking ist eine "Sparvariante" des 
Preemptive-Multitaskings. Diese Art des Multitaskings beruht 
ursprünglich auf den zyklischen Interrupts für den Bildschirm- 
aufbau. Durch diese "Vertical Blank Interrupts" wird der Prozes- 
sor (wie beim Preemptive-Multitasking) angehalten, und der 
Rechner verzweigt zu einer Interrupt-Behandlungsroutine. Das 
Betriebssystem verwaltet eine Liste der sogenannten "Interrupt 
Tasks", der Prozesse, die während der Interrupt-Zeit aufgerufen 
werden. Eine Interrupt-Task kann in 1/60 Sekunden-Einheiten 
spezifizieren, wie oft sie aufgerufen werden soll. Das Interrupt- 
getriebene Multitasking wird hauptsächlich für kurze, zeitab- 
hängige Systemoperationen wie Netzkommunikation, Datei- 
übertragung im Netz oder das Zeichnen des Maus-Cursors ver- 
wendet. Einige Applikationen verwenden Interrupt-Tasks, um 
Zeitmessungen oder andere, zeitabhängige Operationen wie 
Meßwerterfassung zu implementieren. Da jedoch einige wesent- 
liche Beschränkungen beim Programmieren einer Interrupt-Task 
bestehen, läßt sich das Interrupt-getriebene Multitasking nicht 
verwenden, um komplette Applikationen auf dieser Ebene auf- 


Das Interrupt- 
Multitasking unterbricht 
die laufenden Program- 
me, um die Abarbeitung 
systemnaher Prozesse 
(wie z.B. Netzkommuni- 
kation) zu ermöglichen. 
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zubauen. Eine Interrupt-Task ist meistens ein kleines, zeitab- 
hängiges Glied einer Gesamtapplikation oder ein Teil des Be- 
triebssystems. 

Auf dem Macintosh existiert das Interrupt-Multitasking parallel 
zu dem oben beschriebenen Cooperative-Multitasking. Die 
Programmebene wird vom Cooperative-Multitasking beherrscht, 
das Interrupt-getriebene Multitasking wird häufig für Netz- 
kommunikation und Zeitmessung etc. auf Betriebssystemebene 
verwendet. 








Mit diesem Teil des Buches beginnt der Einstieg in die Program- 
mierung des Macintosh. Im Wesentlichen werden in diesem Teil 
das Betriebssystem (Speicherverwaltung, Dateizugriff, Resources) 
und QuickDraw vorgestellt. Die hier vorgestellten Basis-Konzepte 
der Macintosh-Programmierung finden ihre Anwendung in den 
nachfolgenden Kapiteln, die sich mit der Anwendung der ToolBox 
beschäftigen. 


Kapitel 3 gibt zunächst grundsätzliche syntaktische und kon- 
zeptionelle Hinweise für die Macintosh-Programmierung mit Hilfe 
der Programmiersprache C. 


Kapitel 4 gibt dann eine Einführung in die Speicherverwal- 
tungstechnik des Macintosh. Hier wird die neuartige Konzep- 
tion der flexiblen Speicherverwaltung anhand von Beispiel- 
programmen demonstriert. 


Kapitel 5 beschreibt das Dateisystem des Macintosh bzw. den 
Dateizugriff mit Hilfe des File-Managers. Die Routinen und 
Datenstrukturen werden anhand von kurzen Programmfrag- 
menten praxisbezogen vorgestellt. 


Kapitel 6 erläutert das (schon öfter erwähnte) Konzept der 
Resources. In diesem Kapitel wird demonstriert, wie man das 
Konzept der Resources in die Erstellung eines Macintosh-Pro- 
gramms mit einbezieht. Die Routinen und Datenstrukturen, die 
dazu benötigt werden, sind an Beispielen erläutert. 





a... Kapitel 7 beschreibt die Grafikbibliothek des Macintosh. Dieses 


Kapitel stellt die wichtigsten Datenstrukturen und Routinen von 
QuickDraw, dem Basis-Grafikpaket des Macintosh, vor. 
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Dieses Kapitel gibt einen Überblick über, bzw. Lösungsmög- 
lichkeiten für, die Problematik der Macintosh-Programmierung 
mit Hilfe der Programmiersprache C. Es ist als vorbereitender 
Einstieg in die Macintosh-Programmierung gedacht. 


Der Macintosh ist eigentlich eine Pascal-Maschine. Die Schnitt- 
stellen der einzelnen OASIS-Schichten beruhen auf der Pro- 
grammiersprache Pascal, ein Großteil der ToolBox- und Be- 
triebssystem-Routinen sind in dieser Programmiersprache im- 
plementiert. 

Auch die Dokumentation über die Programmierschnittstelle 
(ToolBox und Betriebssystem) ist im wesentlichen auf die Pro- 
grammiersprache Pascal ausgerichtet. Die sechsbändige Stan- 
dard-Dokumentation "Inside Macintosh", welche die Beschrei- 
bung dieser Schnittstellen und Datenstrukturen beinhaltet, be- 
schreibt ausschließlich das Pascal-Interface der Routinen bzw. 
die Pascal-Versionen der Datenstrukturen. 

Trotzdem programmieren etwa 50 Prozent der Macintosh-Pro- 
grammierer in der populären Sprache C. Apple bemüht sich da- 
her in letzter Zeit, die Unterstützung für die C-Programmierer- 
Gruppe unter den Macintosh-Programmierern zu verbessern. 
Dieses Buch soll ebenfalls einen Beitrag dazu leisten. 

Die meisten Entwicklungsumgebungen für den Macintosh un- 
terstützen die Programmierung des Macs mit Hilfe von C. Zu 
diesem Zweck bietet die Entwicklungsumgebung MPW-Shell (auf 
die in diesem Buch bezug genommen wird) einen ANSI-C- 
Compiler sowie Interface-Dateien, die die Schnittstellendeklaration 


Die Schnittstellen zu 
TooIBox- und Betriebs- 
systemroutinen basieren 
auf Pascal, sie können 
jedoch auch mit Hilfe 
der Programmierspra- 
che C benutzt werden. 


Ein Pascal-String 
besteht aus einem 
Length-Byte und bis zu 
255 Zeichen. 


zu den ToolBox-Routinen bzw. Datenstrukturen in C enthalten. 
Man kann die Pascal-ToolBox-Routinen des Macintosh ohne 
weiteres aus einem in C geschriebenen Programm aufrufen. Auch 
die Debugging-Umgebungen unterstützen diese Programmier- 
sprache, so daß fast von einem Rundum-Support für C gesprochen 
werden kann. 

Ein Problem bleibt jedoch bestehen; die Dokumentation zu den 
ToolBox-Routinen bzw. zum Betriebssystem ist ausschließlich für 
Pascal vorhanden. Es existiert also keine C-Version des "Inside 
Macintosh". Mit etwas Übung kann man jedoch auch mit dieser 
kleinen Hürde fertigwerden. Die C-Versionen der Schnittstellen 
bzw. Datenstrukturen unterscheiden sich nur wenig von den 
Pascal-Versionen. 

Einige Probleme entstehen jedoch durch die Verwendung von 
Pascal-Strings in der Schnittstelle einiger ToolBox-Routinen. 


Ein Pascal-String ist ein Array bestehend aus einem Length-Byte 
und 255 Zeichen. Das Length-Byte enthält die Anzahl der nach 
diesem Byte folgenden Zeichen. Ein Pascal-String unterscheidet 
sich daher erheblich von der C-Version eines Strings, in der es 
anstelle des vorangestellten Length-Bytes einen Null-Terminator 
am Ende des Strings gibt. Weiterhin besteht ein Unterschied in 
der maximalen Länge der Strings: Während ein Pascal-String 
maximal 255 Buchstaben enthalten kann, gibt es durch die Ver- 
wendung eines Null-Terminators inC keine Begrenzung der String- 
Länge. Ein anderer Konzeptionsunterschied liegt darin, daß ein 
Pascal-String (zumindest ein Str255) immer 256 Bytes im Speicher 
belegt (auch wenn er nur drei oder vier Zeichen lang ist). Damit 
Pascal-Programmierer auch mal Speicherplatz sparen können, 
gibt es verschiedene Versionen eines Pascal-Strings: 


Str255 1 Length-Byte, 255 Zeichen 
Str63 1 Length-Byte, 63 Zeichen 
Str32 1 Length-Byte, 32 Zeichen 
Str27 1 Length-Byte, 27 Zeichen 
Str15 1 Length-Byte, 15 Zeichen 





Pascal Str255 


EIBEBIRe Eume 








C-String 


[#lelılıle 
01234 








san] 
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Viele ToolBox- und Betriebssystem-Routinen verlangen einen 
solchen Pascal-String als Parameter. So ist zum Beispiel die 
QuickDraw-Funktion DrawString, die Text auf den Bildschirm 
ausgeben kann, wie folgt deklariert: 


pascal void DrawString (Str255 *s); 


Diese Funktion erwartet die Adresse eines Pascal-Strings, der 
auf dem Bildschirm ausgegeben werden soll. Ein in C geschrie- 
benes Macintosh-Programm muß sich an diese Übergabe-Para- 
meter halten (auch wenn es den meisten C-Programmiereren et- 
was schwer fallen wird), es muß die Pascal-Stringverwaltung 
(zumindest bei ToolBox-Aufrufen) übernehmen. 

Die oben beschriebenen Pascal-String-Versionen sind in den In- 
terface-Dateien der Entwicklungsumgebungen deklariert, können 
also in C-Programmen direkt benutzt werden. Das folgende 
Programmfragment benutzt einen Pascal-String zur Ausgabe mit 
Hilfe von DrawString. 


DrawString ("\pHallo mit C"); 


Hier wird die String-Konstante direkt an die Funktion DrawString 
übergeben. Wir brauchen nicht den Adreßoperator "&" zu ver- 
wenden, um die geforderte Adresse eines Str255 zu übergeben, 
da der C-Compiler dies bei einer String-Konstanten sowieso schon 
macht. Etwas ungewöhnlich ist der Anfang des Strings: das "\p" 
vor dem eigentlichen String veranlaßt den C-Compiler, einen 
"Zwitter-String" zu generierten. Ein solcher String hat sowohl 





Abb. 3.1 

Der Unterschied 
zwischen einem Pascal- 
und einem C-String. 


Das 'pascal'-Keyword 
bedeutet, daß die 
Variablenübergabe bei 
einem Aufruf dieser 
Funktion im Pascal-Stil 
erfolgen soll (die 
Reihenfolge, in welcher 
die Variablen auf den 
Stack gelegt werden). 
Sämtliche ToolBox- und 
Betriebssystemroutinen 
sind als "Pascal"- 
Routinen deklariert, der 
C-Compiler übergibt die 
Variablen bei einem 
Aufruf dieser Routinen 
in der Reihenfolge, wie 
sie von den Routinen 
erwartet wird. 


PLstremp 


PLstrepy 





ein Length-Byte vorweg, als auch einen NULL-Terminator am 
Ende. Er kann daher sowohl für Pascal-Aufrufe wie für C-Routinen 
verwendet werden. Durch diese Technik werden jedoch die Be- 
schränkungen Pascals bezüglich der Länge eines Strings nicht 
aufgehoben; ein solcher "Zwitter-String" kann auch nur maximal 
255 Zeichen enthalten ! 


Es besteht auch die Möglichkeit, Variablen vom Typ eines Pascal- 
Strings in einem C-Programm zu verwenden, die Pascal-Strings 
sind (wie beschrieben) in den Interface-Dateien der Entwick- 
lungsumgebungen deklariert. Die folgenden typedef-Anweisungen 
sind der Macintosh-Entwicklungsumgebung "MPW-Shell" ent- 
nommen: 


typedef unsigned char Str255[256], Str63[64], 
Str32[33], Str31[32], Str27[28], Str15[16], 
*StringPtr, **StringHandle; 


Die C-Pascal-Strings sind als Array of Char deklariert. In diesen 
Arrays enthält das erste Zeichen (Str255[0]) das Pascal-Length- 
Byte. Ein StringPtr ist die Adresse eines solchen Pascal-String- 
Arrays. Die Deklaration eines StringHandles ist ein spezielles 
Konzept des Macintosh-Memory-Managements, welches im 
nachfolgenden Kapitel erklärt wird. 

Für die Bearbeitung von Pascal-Strings stehen in der Ent- 
wicklungsumgebung MPW-Shell unter anderem die folgenden 
Pascal-String-Verwaltungsroutinen zur Verfügung, um dem C- 
Programmierer das Leben mit Pascal-Strings zu erleichtern: 


pascal short PLstrcmp ( StringPtr strl, 
StringPtr str2); 


Die Funktion PLstremp vergleicht die beiden Pascal-Strings und 
gibt die Position des ersten unterschiedlichen Zeichens zurück. 


Sind beide Strings gleich, so gibt PLstremp den Wert 0 zurück. 


pascal StringPtr PLstrcpy ( StringPtr strl, 
StringPtr str2); 


Kopiert den Inhalt des zweiten Strings in den ersten. 





pascal void PLstrcat ( StringPtr strl, 
StringPtr str2); 


PLstrcat 
Hängt den zweiten Pascal-String an den ersten an. 
pascal short PLstrlen (StringPtr str); PLstrien 
Gibt die Länge des Pascal-Strings zurück. Dies entspricht dem 
Wert des ersten Zeichens (Length-Byte). 
Das folgende kleine Beispiel demonstriert die Verwendung eines 
Pascal-Strings als Variable: 
1: void Ausgabe (void) Anmerkung: In diesem 
2: f Beispiel müßte eigent- 
a, Ku lich die (später erklärte) 
4: : 
5: PLstrcpy (myString, "\pHallo mit C"); Ne Type- 
6: DrawString (myString); Castings angewandt 
7:2} werden, um die Adresse 
des Pascal-Strings in 


Hier wird die Variable myString als Str255 deklariert und mit einen StringPtr zu 
Hilfe der Funktion PLstrcpy auf "Hallo mitC" gesetzt. Die Adresse verwandeln. 
dieser Variablen wird anschließend an die Funktion DrawString 

übergeben, die diesen String dann auf dem Bildschirm ausgibt. 


Es existieren sehr viele Pascal-Datenstrukturen, die bei einem 
Aufruf von ToolBox-Routinen verwendet werden. Diese im "Inside 
Macintosh" deklarierten und erklärten Datenstrukturen werden 
auch von C-Programmen benutzt. In den C-Entwicklungsum- 
gebungen existieren äquivalente C-Datenstrukturen, die an die 





ToolBox-Routinen übergeben werden können. Beispielsweise gibt 
es die folgende Pascal-Deklaration eines Event-Records: 


1: TYPE EventRecord = RECORD 
2 what: INTEGER; 
3% message: LONGINT; 
4: when: LONGINT; 
5% where: Point; 

6 modifiers: INTEGER; 
7: END; 


Die äquivalente C-Datenstruktur sieht dann so aus: 


struct EventRecord { 


1: 

2 short 
3: long 
4: long 
53 Point 
6 short 
1:25 


what; 
message; 
when; 
where; 
modifiers; 


Die beiden Datenstrukturen belegen exakt dieselbe Anzahl an 
Bytes im Speicher, die einzelnen Felder befinden sich auch an 
den gleichen Positionen. Daher kann die C-Datenstruktur auch 


an ToolBox-Routinen 


übergeben werden (die ja in Pascal ge- 


schrieben worden sind). 
Generell gibt es die folgenden Pascal-Basis-Typen bzw. ihre C- 


Äquivalente: 


Pascal 


Char 
Integer 
LongInt 
Str255 
Pointer 


@ 


c 


char 
short 
long 
Str255 
Ptr 

& 


Anstelle des in vielen Pascal-Beispiel-Programmen verwende- 
ten Pascal-Adreßoperators "@" wird inC "&" verwendet, um die 
Adresse einer Variablen zu übergeben. 


Viele ToolBox-Routinen haben mehrere Ergebniswerte. Da auch 
eine Pascal-Funktion nur einen direkten Ergebniswert haben kann, 
existiert in Pascal zusätzlich zu dem Funktionsergebniswert die 
Möglichkeit, einen Übergabe-Parameter als VAR-Parameter zu 
deklarieren. Die folgende Pascal-Deklaration der ToolBox-Funktion 
GetNextEvent benutzt diese Möglichkeit: 


FUNCTION GetNextEvent ( 
eventMask: INTEGER; 
VAR theEvent: EventRecord) : BOOLEAN; 


Hier ist der Parameter theEvent, der vom Typ EventRecord sein 
muß, als VAR-Parameter deklariert. Diese VAR-Deklaration 
bedeutet, daß die Funktion den Inhalt der übergebenen Varia- 
blen ändert. Dieser Parameter stellt also einen zusätzlichen 
Ergebniswert dar. 

Die korrespondierende C-Deklaration der Funktion GetNextEvent 
sieht folgendermaßen aus: 


pascal Boolean GetNextEvent ( 
short eventMask, 
EventRecord *theEvent); 


In der C-Version wird die Funktion so deklariert, daß ihr die 
Adresse eines EventRecords übergeben werden muß. Die Funktion 
GetNextEvent kann daher auch auf die übergebene Variable 
zugreifen und deren Werte verändern. 

Das folgende Programmfragment zeigt die Übergabe eines VAR- 
Parameters in C: 


l: void DoEvent (void) 

2: { 

3° EventRecord myEvent; 

4: Boolean gotEvent; 

5: 

6: gotEvent = GetNextEvent (everyEvent, 
&myEvent); 

Has 


Ein VAR-Parameter ist 
ein zusätzlicher 
Ergebniswert einer 
Funktion. 


In Zeile 12 und 13 wird 
die lokale Variable 
myRectPtr dereferen- 
ziert, um auf das Feld 
top zuzugreifen. 


Hier wird in Zeile 6 die Adresse des EventRecords myEvent 
übergeben, indem der Adreßoperator "&" vor die Variable gesetzt 
wird. GetNextEvent kann so den Inhalt der Variablen ändern. 
Immer wenn Sie in der Pascal-Deklaration einen VAR-Parame- 
ter sehen (im "Inside Macintosh"), so können Sie davon ausge- 
hen, daß sie bei einem Aufruf der C-Version den Adreßoperator 
"&" vor den Parameter setzen müssen. Sie können natürlich auch 
bei der C-Deklaration der Routine in der entsprechenden Inter- 
face-Datei nachsehen. Mit der Zeit gewöhnt man sich aber auto- 
matisch an, zu erkennen, wieman vonC aus eine Pascal-Routine 
aufruft. 


Dereferenzierung ist eine sehr häufig verwendete Technik bei 
der Macintosh-Programmierung. Die Dereferenzierung stellt keine 
besondere Hürde bei der Macintosh-Programmierung dar, ich 
möchte jedoch trotzdem kurz darauf eingehen. 

Bei der Dereferenzierung eines Pointers bestehen zwei verschie- 
dene Möglichkeiten: 


1. Verwendung des "->"-Operators. 
2. Benutzung des "*"-Operators in Verbindung mit Klammern. 


Die folgenden Zeilen bewirken das Setzen derselben Variablen 
im selben struct. Nur die Schreibweise unterscheidet sich ein wenig: 


1: struct Rect { 

2: short top, left, bottom, right; 
3: } 

4: 

5: typedef Rect Rect; 

6: 

7: Rect *myRectPtr; 

8: 

9: void main (void) 
10: { 
L1: myRectPtr = &Rect; 
12: myRectPtr->top = 5; 
13: (*myRectPtr)..top = 5; 


3.6 Type-Casting 





In Zeile 1 bis 3 wird die Struktur Rect deklariert und angelegt. 
Zeile 7 deklariert die Variable myRectPtr als Adresse eines Rects. 
In Zeile 11 wird myRectPtr die Adresse des Rects zugewiesen. 
Zeile 12 und 13 bewirken beide dasselbe. Beide setzen das Feld 
top in dem struct Rect auf den Wert 5. Zeile 12 tut dies mit Hilfe 
des "->" Operators, Zeile 13 mit Hilfe des "*"-Operators. Bei der 
letzten Schreibweise muß der zu dereferenzierende Pointer in 
Klammern gesetzt werden. Mit Hilfe von ".top" begibt man sich 
zu der entsprechenden Variablen innerhalb des structs. 

Die etwas umständlichere Schreibweise mit Hilfe des "*"-Ope- 
rators wird bei den im nächsten Kapitel beschriebenen Handle- 
Strukturen benötigt. 


3.6 Type-Casting 


Type-Casting ist eine auf dem Macintosh sehr häufig verwende- 
te Technik, den Compiler von der Überlegenheit des menschli- 
chen Gehirns zu überzeugen. 

Das folgende Beispiel führt (ohne Type-Casting) zu einer Compiler- 
Warnung "long assigned to short": 


1: short myShort; Der C-Compiler 

2: long myLong; akzeptiert nur Zu- 

38 weisungen zwischen 
= a No Variablen gleichen Typs. 
6 myLong = 1; 

7: myShort = myLong; 

8: } 


Die Warnung "long assigned to short" ist korrekt. In Zeile 7 wird 
der längere (32-Bit-) Wert (long) einem kürzerem (16-Bit-) Wert 
(short) zugewiesen. Da die beiden Typen verschieden sind, reagiert 
der Compiler mit der angesprochenen Warnung. 

Um C von der Richtigkeit dieses Programms zu überzeugen, kann 
man in Zeile 7 Type-Casting verwenden, um dem Compiler klar 
zu machen, daß wir wirklich dem short einen long zuweisen wollen. 
Dies geschieht, indem der erwartete Typ in Klammern vor die 
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In Zeile 7 wird der long 
mit Hilfe von Type- 
Casting in einen short 
umgewandelt. 


zu konvertierende Variable gesetzt wird. Nun ist der Compiler 


zufrieden. 
1: short myShort; 
2: long myLong; 
3: 
4: void main (void) 
5: { 
6 mylLong = 1; 
7 myShort = (short) mylong; 
8: } 


Diese Technik wird bei der Programmierung des Macintosh sehr 
häufig verwendet, da viele Datenstrukturen bestehen, die stän- 
dig ausgetauscht, einander zugewiesen oder an Funktionen 
übergeben werden, die etwas anders deklariert sind als die Da- 


ten, die ihnen übergeben werden. In den nachfolgenden Kapiteln 
werden einige Beispiele auftauchen, die u.a. die Technik des Type- 
Castings beim Aufruf von ToolBox-Routinen demonstrieren. 


Kapitel 4 





Die - 
Speicherverwaltung 


Dieses Kapitel ist eine Einführung in die Speicherverwal- 
tungstechniken des Macintosh. Es stellt den "Basis-Pfeiler" der 
Macintosh-Programmierung dar, da die hier vorgestellten Me- 
thoden bei der Benutzung von QuickDraw und ToolBox sehr häufig 
verwendet werden. 

Das Speicherverwaltungskonzept des Macintosh ist etwas ei- 
genwillig, jedoch sehr flexibel. Es wurde als universeller Lö- 
sungsansatz der Speicherverwaltungsproblematik entwickelt. So 
ist es auf Rechnern, die keine Hardware-Unterstützung für vir- 
tuelle Speicherverwaltung bieten (dies sind immer noch die 
meisten) nur durch hohen Programmieraufwand möglich, den 
Speicherbereich optimal auszunutzen. Klassische Betriebssysteme 
bieten als Möglichkeit der dynamischen Speicherverwaltung nur 
das Konzept der Pointer, und erlauben das Anlegen und Freigeben 
von Speicherblöcken mit Hilfe von malloc und free. 











Variablen im Speicher- Abb. 4-1 
Programm bereich " 
Dynamische Daten- 
ame] Daten verwaltung mit Hilfe von 
Pointer , 
Pointern. 
Daten Der Pointer beinhaltet 
die Adresse der Daten. 
—— 











Dieses Konzept birgt jedoch ein wesentliches Problem: Wird im 


Laufe der Programmabarbeitung häufig Speicher angelegt und 
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Abb. 4-2 

Die Fragmentierung des 
Speicherbereiches 
durch Pointer: 

In Schritt 1 werden 3 
Datenblöcke angelegt. 
Schritt 2 gibt den 2. 
Datenblock wieder frei. 
Möchte das Programm 
jetzt einen großen, 
zusammenhängenden 
Datenblock anlegen, so 
liegt der 3. Block im 
Weg. Das Programm 
kann den Speicher- 
bereich nicht optimal 
nutzen. 


wieder freigegeben, so wird der Speicherbereich des Rechners 
fragmentiert. Dies bedeutet, daß dem Programm nach einiger 
Zeit nicht mehr der gesamte freie Speicherbereich als kontinu- 
ierlicher Bereich zur Verfügung steht. Der freie Speicherbereich 
ist in kleine, voneinander getrennte Bereiche unterteilt (frag- 
mentiert). Möchte das Programm nun einen großen, zusammen- 
hängenden Speicherbereich reservieren, so ist dies eventuell nicht 


. möglich, obwohl die Summe aller freien Speicherbereiche noch 


ausreichen könnte. 


Variablen im Speicher- Variablen im Speicher- 
Programm bereich Programm bereich 








free 








mory-Manageı 


Die Speicherverwaltung wird auf dem Macintosh von dem so- 
genannten "Memory Manager" übernommen. Die Routinen dieses 
Managers erlauben das Anlegen bzw. Freigeben von Speicher- 
blöcken. Die Konzeption dieses Managers geht über die klassi- 
sche Konzeption der dynamischen, indirekten Speicherverwaltung 
mittels Pointern hinaus und bietet eine Lösungsmöglichkeit für 
das oben beschriebene Problem der Speicherbereichfragmen- 
tierung. 

Diese Lösung besteht in der doppelt indirekten Speicherver- 
waltung, einer Speicherverwaltung über sogenannte "Handles" 
bzw. "relocatable Blocks". Ein typisches Macintosh-Programm 
verwaltet fast alle dynamischen Daten mit Hilfe dieser Handles. 


Handles sind im Grunde genommen nichts anderes als Pointer 
(also Adressen von Speicherstellen im RAM) mit dem Unterschied, 
daß sie die Adresse eines weiteren Pointers beinhalten. Erst dieser 
sogenannte "Master Pointer" beinhaltet die wirkliche Adresse der 
Daten. 


Ein Handle ist ein Pointer auf einen Pointer. 


Variable im Speicher- 
Programm bereich 





Handle MasterPtr 





Der Sinn der doppelt indirekten Speicherverwaltung mit Hilfe 
von Handles liegt darin, daß die Speicherblöcke, die mit einem 
Handle verwaltet werden, verschiebbar sind. Diese mit einem 
Handle verwalteten Datenblöcke werden daher auch "relocatable 
Blocks" genannt. Wird der Speicherbereich einer Macintosh- 
Applikation durch häufiges Anlegen und Freigeben von Spei- 
cherplatz fragmentiert, so kann der Memory-Manager die 
Datenblöcke neu ordnen, und somit die Fragmentierung des 
Speicherbereichs beheben. Der Vorteil dieser Technologie liegt 
auf der Hand; egal wie oft und in welcher Reihenfolge ein Mac- 
intosh-Programm Speicher anlegt oder freigibt, es läuft nie Ge- 
fahr, den Speicherbereich permanent zu fragmentieren. Auf diese 
Weise kann ein Macintosh-Programm den Speicherbereich optimal 
ausnutzen. 

Die folgende Abbildung demonstriert den Vorgang, der bei der 
Verschiebung eines Datenblocks abläuft: 





Abb. 4-3 

Die Grafik illustriert die 
doppelt indirekte 
Datenverwaltung mit 
Hilfe von Handles. Der 
Handle zeigt auf den 
Master-Pointer, welcher 
letztendlich auf die 
eigentlichen Daten zeigt. 





Abb. 4-4 

Schritt 1 zeigt einen im 
Speicherbereich der 
Applikation liegenden 
Datenblock, der mit 
einem Handle verwaltet 
wird, Im zweiten Schritt 
verlangt das Programm 
einen neuen Datenblock. 
Da der erste Block in der 
Mitte des Speicher- 
bereiches liegt, existiert 
nicht mehr genügend 
freier, kontinuierlicher 
Speicherbereich, um 
den neuen Datenblock 
anzulegen. Der Memory- 
Manager verschiebt jetzt 
den ersten Datenblock, 
um einen kontinuierli- 
chen freien Speicher- 
bereich freizulegen. In 
Schritt 3 wird der neue 
Datenblock in dem 
freigelegten Bereich 
angelegt. 


46 
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Variablen im Speicher- 
Programm bereich 
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Interessant an dieser Technologie ist, daß der Memory-Manager 
die Datenblöcke verschieben kann, ohne das Programm davon 
zu informieren. Wenn der Memory-Manager einen Block ver- 
schiebt, so ändert er den Wert des Master-Pointers, sodaß dieser 
nun die neue Adresse des verschobenen Blocks beinhaltet. Greift 
das Programm das nächste Mal auf den Block zu, so wird es 
automatisch auf den verschobenen Block zugreifen, da der Zugriff 
über den Master-Pointer erfolgt. 


Der Zugriff auf diemit Handles verwalteten Datenblöcke erfolgt indirekt 
über die Master-Pointer. Dadurch können relocatable-Blocks verscho- 
ben werden, ohne das Programm davon zu informieren. 


Diese doppelt indirekte Datenverwaltung mit Hilfe von Hand- 
les und Master-Pointern bedeutet, daß im Gegensatz zur klassi- 
schen Datenverwaltung mit Pointern ein Handle doppelt de- 
referenziert werden muß, um zu den Daten zu gelangen. Das 
folgende Beispiel demonstriert die Dereferenzierung eines Handles, 
um auf die Daten eines relocatable-Blocks zuzugreifen: 





1: struct Rect { 

2: short top, left, bottom, right; 
3: 

4: 

5: typedef Rect Rect; 

6: 

7: Rect **myRectHandle; 

8: 

9: void main (void) 

10: { 

Lt: /* Hier würde der Speicherbereich für 
den Handle mit Hilfe von Memory 
Manager-Routinen angelegt */ 

12: 

13% (**myRectHandle) .top = 5; /*Zuweisung*/ 

14: } 


Im diesem Beispiel existiert die Variable myRectHandle, die als 
Handle auf einen Datenblock von Typ Rect deklariert ist; die Größe 
des von diesem Handle verwalteten Datenblocks entspricht der 
Größe der in den Zeilen 1 bis 3 deklarierten Rect-Struktur. Es 
wird zur Vereinfachung des Beispiels davon ausgegangen, daß 
der Datenblock in Zeile 13 bereits angelegt ist. 

Die Variable myRectHandle wird in Zeile 13 doppelt dereferen- 
ziert, um zu der Rect-Struktur zu kommen, und dort dem Feld 
top den Wert 5 zuzuweisen. Doppelte Dereferenzierung kann in 
C nur mittels des "*"-Operators erreicht werden, wobei der zu 
dereferenzierende Handle in Klammern gesetzt werden muß. 


Das Anlegen und Freigeben von relocatable-Blocks im Speicher- 
bereich einer Applikation (dem sogenannten "Heap") geschieht 
über die Memory-Manager-Funktionen NewHandle und 
DisposeHandle. 

NewHandle reserviert einen Speicherblock, trägt die Adresse des 
angelegten Blocks in einem Master-Pointer ein und gibt die Adresse 
des Master-Pointers (den Handle) als Ergebniswert zurück. 
NewHandle ist deklariert als: 


pascal Handle NewHandle (Size byteCount); 


Um auf die Daten, die 
mit einem Handle 
verwaltet werden, 
zuzugreifen, muß 
doppelt dereferenziert 
werden. 


NewHandle 


Das Beispiel verwendet 
die Memory-Manager- 
Funktion NewHandle, 
um einen relocatable- 
Block mit der Größe 
eines Pascal-Strings 
anzulegen. 


Der Parameter byteCount definiert die Größe des anzulegenden 
Blocks. 

Im folgenden Beispiel soll ein relocatable-Block angelegt wer- 
den, der einen Pascal-String verwaltet, und dieser String soll auf 
"Hallo" gesetzt werden: 


: StringHandle myStringHandle; 


Ad 
myStringHandle = (StringHandle) 
NewHandle (sizeof (Str255)); 
6: PLstrcpy (*myStringHandle, "\pHallo"); 
ER Ausgabe (myStringHandle); 


1 
2: 
3: void main (void) 
4 
5 


Der Typ StringHandle ist deklariert als Handle auf einen Typ 
Str255 (ein Pascal-String). Es muß in Zeile 5 Type-Casting ver- 
wendet werden, um den Compiler davon zu überzeugen, daß 
ein Handle (den die Funktion NewHandle zurückgibt) dasselbe 
ist wie ein StringHandle. Andernfalls würde der Compiler mit 
"Type Conflict of Operands" abbrechen. Das sizeof-Statement 
bewirkt, daß während der Übersetzung des Quelltextes heraus- 
gefunden wird, wie groß ein Str255 ist (natürlich 256 Bytes : 255 
Buchstaben + 1 Length-Byte) und anstelle des sizeof-Statements 
eingesetzt wird. NewHandle legt so einen Block mit der Größe 
von 256 Bytes im Speicherbereich der Applikation an. In Zeile 6 
wird schließlich unser StringHandle auf "Hallo" gesetzt. Dies 
geschieht mit der Funktion PLstrepy, die die Adressen von zwei 
Pascal-Strings erwartet, und den zweiten String in den ersten 
kopiert. Die Verwendung dieser Funktion wird notwendig, da 
es in der Programmiersprache C nicht möglich ist, einen String 
einem anderen zuzuweisen. Wir geben daher als ersten Parame- 
ter den dereferenzierten StringHandle, also die Adresse unseres 
Strings an und als zweiten Parameter "\pHallo". Das "\p" ist (wie 
im vorangegangenen Kapitel beschrieben) ein "Trick", um in der 
Programmiersprache C einen Pascal-String zu erzeugen. 


Variable im 
Programm 


Speicher- 
bereich 
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bereich 
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Das kleine Programm hat noch ein Problem: Es wird ein Block 
im Speicherbereich der Applikation angelegt, jedoch nach Be- 
nutzung nicht wieder freigegeben. Wenn ein mit NewHandle 
angelegter relocatable-Block wieder freigeben werden soll, kann 
die Memory-Manager-Funktion DisposeHandle verwendet 
werden, die wie folgt deklariert ist: 


pascal void DisposeHandle (Handle h); 


Die Funktion DisposeHandle gibt den relocatable-Block frei, der 
mit dem Parameter h spezifiziert wird. DerMemory-Manager kann 
den Speicherbereich des Blocks beim nächsten NewHandle-Aufruf 
überschreiben. 

Die verbesserte Version des vorangegangenen Beispiels benutzt 
DisposeHandle, um den Block nach der Ausgabe wieder freizu- 
geben. 


: StringHandle myStringHandle; 


2 dt 


1 
28 
3: void main (void) 
4 
5 


myStringHandle = (StringHandle) 
NewHandle (sizeof (Str255)); 
6 PLstrcepy (*myStringHandle, "\pHallo"); 
71: Ausgabe (myStringHandle); 
8: DisposeHandle ((Handle) myStringHandle); 
9 


Wenn der Speicherbereich einer Applikation nicht mehr genü- 
gend freien Speicherplatz enthält, um einen Block von der ange- 
forderten Größe anzulegen, so gibt NewHandle den Wert NULL 
zurück. Dies würde in der bisherigen Form des Beispiel-Programms 


Abb. 4-5 

Die Grafik illustriert den 
beschriebenen Vorgang. 
Zunächst wird in Schritt 
1 ein Handle mit der 
Größe von 256 Bytes im 
Speicherbereich der 
Applikation angelegt. 
Dieses Anlegen des 
relocatable-Blocks 
geschieht über den 
Aufruf der Funktion 
NewHandle. In Schritt 2 
wird mit Hilfe der 
Funktion PLstropy der 
Pascal-String "\pHallo" in 
den Datenblock 
geschrieben. Der 
StringHandle verwaltet 
jetzt einen Pascal-String 
mit dem Inhalt "Hallo”. 


Wenn die Daten eines 
relocatable-Blocks nicht 
mehr benötigt werden, 
dann wird die Funktion 
DisposeHandle 
aufgerufen. 





In dieser Version der 
Beispielfunktion wird 
der Ergebniswert von 
NewHandle mit NULL 
verglichen, um 
festzustellen, ob die 
Alloziierung erfolgreich 
war. 





wahrscheinlich zu einem Absturz führen, da dann in Zeile 6 der 
Inhalt der Speicherstelle NULL an PLstrcpy übergeben würde. Da 
der Inhalt der Speicherstelle 0 undefiniert ist, würde PLstrepy den 
String "Hallo" irgendwo in den Speicherbereich des Rechners 
schreiben (ein sicherlich ungesundes Verhalten). Eine Lösung für 
dieses häufig auftretende Problem ist die Abfrage des Ergebnis- 
wertes der Funktion NewHandle. Die verbesserte Version des 
kleinen Programms: 


: StringHandle myStringHandle; 


Ad 
myStringHandle = (StringHandle) 
NewHandle (sizeof (Str255)); 


1 
2: 
3: void main (void) 
4 
5 


6 i£ (myStringHandle == NULL) 

les Fehlerbehandlung (kNoMemory); 

8 else : 

9: { 

10: PLstrcpy (*myStringHandle, "\pHallo"); 
11: Ausgabe (myStringHandle); 

12: DisposeHandle ((Handle)myStringHandle); 
13: } 

14: } 


In Zeile 6 wird jetzt zunächst abgefragt, ob die Alloziierung des 
relocatable-Blocks erfolgreich war. Ist die Alloziierung nicht er- 
folgreich verlaufen (myStringHandle ist NULL), so wird in eine 
Fehlerbehandlungsroutine verzweigt. 


Um Sie auf ein weiteres, recht kompliziertes Problem des Memory- 
Managements mit Handles hinzuweisen, wird die Funktion 
Ausgabe implementiert: 


1: void Ausgabe (StringHandle theStringHandle); 
Su! 
DrawString (*theStringHandle); 


DD WM 


Die Funktion Ausgabe nimmt einen StringHandle als Parameter 
und benutzt dieQuickDraw-Funktion DrawString, um den String 
auf den Bildschirm zu zeichnen. DrawString ist deklariert als: 





pascal void DrawString (Str255 *s); 


In Zeile 3 wird der StringHandle theStringHandle derefe- 
renziert, um die QuickDraw-Funktion DrawString mit der ge- 
forderten Adresse eines Pascal-Strings zu füttern. 


Wir übergeben an dieser Stelle also weder den String selbst, noch den 
StringHandle, sondern die Adresse des Strings im RAM. 


DrawString hat die Eigenschaft, während der Ausführung tem- 
porär Speicherplatz im Speicherbereich der Applikation anzule- 
gen. Nehmen wir einmal an, unser Speicherbereich ist schon 
ziemlich voll, und die Prozedur DrawString verlangt mittels Ne- 
wHandle vom Memory-Manager einen temporären Block. 

Ist in unserem Speicherbereich nicht mehr genügend kontinu- 
ierlicher, freier Speicherplatz vorhanden, so wird der Memory- 
Manager versuchen, durch das Verschieben vonrelocatable-Blocks 
einen kontinuierlichen, freien Speicherbereich freizulegen. Ge- 
nau da liegt jedoch das potentielle Problem; wir haben DrawString 
die Adresse unseres mit einem Handle verwaltetem Strings ge- 
geben, der String selbst ist also relocatable, verschiebbar. Wird 
der String verschoben, weil DrawString temporären Speicher- 
platz anfordert, so wird DrawString falsche Buchstaben ausge- 
ben, da DrawString immer noch die alte Adresse des Strings be- 
nutzt, um auf die Daten zuzugreifen. 

Dieses Problem ist eine der größten Fehlerquellen bei der Pro- 
grammierung des Macintosh. Verschärft wird dieses Problem 
dadurch, daß es sehr schwierig ist, diese Fehler zu finden, denn 
sie treten eben nur in den Situationen auf, in denen der Memory- 
Manager nicht mehr genügend Speicherplatz hat, um den tem- 
porär angeforderten Bereich zu alloziieren. Ist noch genügend 
Speicherplatz vorhanden, so wird der Memory-Manager den Block, 
in dem sich der String befindet, nicht verschieben und alles 
funktioniert blendend. 

Um dem Problem Herr zu werden, kann man dafür sorgen, daß 
sich der String während der Ausführung von DrawString nicht 
verschiebt. Dies erreicht man mit der Memory-Manager-Funk- 
tion HLock. HLock sorgt dafür, daß ein verschiebbarer Block für 
den Memory-Manager als nonrelocatable (nicht verschiebbar) 





Wenn man einer 
Routine, die während 
Ihrer Ausführung 
Datenblöcke alloziiert, 
die Adresse eines 
relocatable-Blocks 
übergibt, dann kann dies 
zu Fehlern führen, da 
der relocatable-Block 
während der Abarbei- 
tung der Funktion 
verschoben werden 
kann. 

Da die Funktion mit der 
Adresse des 
relocatable-Blocks 
arbeitet, greift sie, 
nachdem der Block 
verschoben wurde, 
immer noch auf die alte 
Adresse des Blocks zu. 


HLock 


HUnlock 


gekennzeichnet wird. Der Memory-Manager wird dann nicht 
versuchen, den Block zu verschieben, und das Problem mit 
DrawString ist elegant gelöst. 


Die Funktion HLock ist wie folgt deklariert: 
pascal void HLock (Handle h); 


Diese Funktion des Memory-Managers kennzeichnet den Block, 
auf den der übergebene Handle zeigt, als nonrelocatable (nicht 
verschiebbar). Der Memory-Manager wird diesen Block nicht mehr 
verschieben. 


Das Gegenstück zu HLock heißt HUnlock. Diese Funktion hebt 
die Wirkung von HLock wieder auf. 


pascal void HUnlock (Handle h); 


Ein vorher als locked gekennzeichneter Block wird nach dem 
Aufruf von HUnlock wieder relocatable (verschiebbar). 


Die verbesserte Version der Funktion Ausgabe: 


1: void Ausgabe (StringHandle theStringHandle); 
2: { 

35 HLock ((Handle) theStringHandle); 

4 DrawString (*theStringHandle); 

2) HUnlock ((Handle) theStringHandle); 

6: } 


In Zeile 3 sorgt die verbesserte Version mit Hilfe der Funktion 
HLock dafür, daß sich der relocatable-Block während der Aus- 
führung von DrawString nicht verschieben kann. Auf diese Weise 
kann in Zeile 4 unbesorgt die Adresse des relocatable-Blocks an 
DrawString übergeben werden. In Zeile 5 wird schließlich dafür 
gesorgt, daß der "gelockte" Block wieder verschiebbar wird, in- 
dem die Funktion HUnlock aufgerufen wird. 

Man sollte einen Handle, den man "gelockt" hat, möglichst bald 
wieder "unlocken", damit einer Fragmentierung des Speicherbe- 
reichs vorgebeugt wird. Ein als gelockt markierter Block frag- 


mentiert den Speicherbereich, da dieser Block vom Memory- 
Manager nicht verschoben werden kann, wenn er den Speicher- 
bereich neu organisieren will. 

Zusammengefaßt kann man sagen: 


Immer wen man einer Funktion, die eventuell Speicher alloziiert, die 
Adresse eines relocatable-Blocks übergibt, so muß dieser Block vorher 
gelockt und hinterher ungelockt werden. 


Die ToolBox-Funktionen, die während ihrer Ausführung temp- 
orären Speicher anlegen, sind im "Inside Macintosh" Appendix 
B "Routines that may move or purge memory" enthalten. 


Es gibt auf dem Macintosh auch nonrelocatable-Blocks, also Blocks, 
die nicht per Handle, sondern direkt mit einem Pointer verwaltet 
werden. Diese nonrelocatable-Blocks entsprechen der klassischen 
dynamischen Datenverwaltung mit Hilfe von malloc und free. 
Mit Hilfe von NewPtr kann man einen nonrelocatable-Block im 
Speicherbereich der Applikation anlegen. 


pascal Ptr NewPtr (Size byteCount); 


Die Anzahl der anzulegenden Bytes wird mit dem Parameter 
byteCount angegeben. 


Die Funktion DisposePtr gibt den nonrelocatable-Block, dessen 
Adresse als Parameter übergeben wird, wieder frei. 


pascal void DisposePtr (Ptr p); 


Der von diesem Block belegte Speicherplatz steht dem Memory- 
Manager zum Überschreiben zur Verfügung. 


Wie das Attribut "nonrelocatable" schon sagt, sind die mit NewPtr 
angelegten Blöcke nicht verschiebbar und bergen damit das Pro- 
blem der permanenten Fragmentierung des Speicherbereichs in 


NewPtr 


DisposePtr 


Be 


un 





Abb. 4-6 

Der Speicherbereich 
einer Applikation, der 
durch einen 
nonrelocatable-Block 
(grau gekennzeichnet) 
permanent fragmentiert 
ist. Diese Fragmentie- 
rung bewirkt, daß der 
Memory-Manager nicht 
den gesamten Speicher- 
platz zur Verfügung hat, 
um relocatable-Blocks 
neu zu ordnen, wenn 
dies nötig ist. 








sich. Diese nonrelocatable-Blocks stören den Memory-Manager 
beim "Platzschaffen". In einigen wenigen Fällen kann es nötig 
werden, nonrelocatable-Blocks anzulegen. Wenn möglich, sollte 
die Verwendung von relocatable-Blocks zur Datenverwaltung 
der Verwendung von nonrelocatable-Blocks vorgezogen werden. 


Man sollte nonrelocatable-Blocks wenn möglich vermeiden oder nur 
kurzzeitig anlegen und dann sofort wieder freigeben. 


Sollten Sie in Ihrem Programm nonrelocatable-Blocks benötigen, 
die über längere Zeit bestehen sollen, so sollten diese möglichst 
früh angelegt werden, da sie zu diesem Zeitpunkt nicht zu einer 
permanenten Fragmentierung des Speicherbereiches führen. Der 
Memory-Manager versucht, Blöcke, die mit NewPtr angelegt 
werden möglichst weit "oben" anzulegen und verschiebt 
relocatable-Blocks, die im Wege liegen. Liegt ein nonrelocatable- 
Block "ganz oben", so fragmentiert er den Speicherbereich nicht; 
der Memory-Manager hat den restlichen Speicherbereich als 
kontinuierlichen Speicherplatz zu seiner freien Verfügung. 
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Dieses Kapitel beschäftigt sich mit dem Aufbau und dem Zu- 
griff auf das Macintosh-Dateisystem. Zunächst wird die Ver- 
bindung zwischen Ikonen und Dateien erläutert bzw. erklärt, wie 
die verschiedenen Dateiformate unterschieden werden. An- 
schließend werden Routinen und Datenstrukturen für den Zugriff 
auf das Dateisystem vorgestellt. Dieser Zugriff wird dann anhand 
von Programmfragmenten erläutert. 


Das Macintosh-Dateisystem unterscheidet sich auf unterer Ebe- 
ne nur wenig von anderen Dateisystemen. Es ist ein hierarchi- 
sches Dateisystem, daß keine Begrenzungen bezogen auf die 
hierarchische Tiefe der Ordner hat. Das Macintosh-Betriebssystem 
erlaubt jedoch, im Gegensatz zu vielen anderen Systemen, die 
Vergabe von langen Dateinamen (bis zu 31 Zeichen), die auch so 
gut wie alle Sonderzeichen enthalten können. Eine Macintosh- 
Datei ist, wie bei anderen Betriebssystemen, ein Byte-Stream, der 
Schreib /Lese-Zugriff auf eine Datei erfolgt über einen File-Pointer, 
welcher die momentane Schreib/Lese-Position innerhalb der 
geöffneten Datei markiert. 

Der Typ einer Macintosh-Datei wird durch einen sogenannten 
"File Type" (vier Zeichen) charakterisiert. Dieser File-Type ist nicht 
Teil des Dateinamens (wie bei MS-DOS .txt oder .bat), sondern 
wird vom Betriebssystem, sozusagen im Hintergrund, verwaltet. 
Anhand dieses File-Types kann das Betriebssystem unterscheiden, 
ob es sich bei einer Datei um eine Applikation, oder z.B. um eine 
Textdatei handelt. Die folgende Auflistung stellt die verschiedenen 
Standard-File-Types und ihre Bedeutung dar: 


Auf dem Macintosh wird 
der Dateityp durch vier 
(Case-Sensitive) 
Zeichen unterschieden. 


Die Verbindung 
zwischen File-Type, 
Creator-Type und Icon. 
Die Ikone, welche im 
Finder dargestellt wird, 
ergibt sich aus der 
Kombination von File- 
Type und Creator-Type. 


'APPL' - Eine Applikation 


"TEXT - Eine Textdatei 
'EPSF' - Eine PostScript-Grafikdatei 
'PICT - Eine Macintosh-spezifische Grafikdatei 


Weiterhin kann jede Macintosh-Applikation einen oder mehrere 
eigene File-Types besitzen, unter denen Dateien abgespeichert 
werden, die dann von anderen Programmen nicht gelesen wer- 
den können. Unter einem privaten File-Type speichern Macintosh- 
Applikationen Daten, die in einem eigenen, nicht standardisierten 
Datenformat aufgebaut sind. 

Neben dem File-Type assoziiert das Macintosh-Betriebssystem 
zu jeder Datei vier weitere Zeichen, den sogenannten "Creator 
Type". Dieser Creator-Type einer Datei ist sozusagen die Unter- 
schrift der Applikation, die diese Datei angelegt hat. Der Finder 
benutzt den Creator-Type und den File-Type, um aus einer, vom 
Betriebssystem verwalteten Datenbank die Ikone (Icon) heraus- 
zusuchen, welche er für diese Datei darstellen soll. 

Die folgende Auflistung veranschaulicht die Beziehung zwischen 
File-Type, Creator-Type und den Icons der Grafikapplikation 
MacDraw: 


File-Type E Creator-Type = Icon 


PIET' + 'MDRW' 


'APPL' + 'MDRW' = 





Der Creator-Type einer Datei wird auch dazu verwendet, um 
die Applikation zu finden, welche gestartet werden soll, wenn 
der Benutzer auf die Datei doppelklickt. Ein Creator-Type sowie 
ein privater File-Type (falls benötigt) sollte vor Auslieferung einer 
Applikation bei Apple beantragt werden, da sonst (verständli- 
cherweise) Konflikte mit anderen Applikationen möglich sind, 
wenn diese denselben Creator-Type verwenden. In der Ent- 
wicklungsphase einer Applikation kann man möglichst unübli- 





che Zeichenkombinationen wie 'XP1U' für den Creator-Type bzw. 
für einen eigenen File-Type verwenden. 

An dieser Stelle wird wieder einmal deutlich, daß das Macintosh- 
Gesamtsystem wesentliche Vorteile gegenüber Betriebssystemen 
hat, auf die nachträglich eine grafische Benutzeroberfläche auf- 
gesetzt wurde. Das Betriebssystem des Macs wurde für die Im- 
plementierung einer grafischen Benutzeroberfläche konzipiert. 
Diese Verquickung von Benutzeroberfläche und Betriebssystem 
bewahrt den Macintosh-Benutzer davor, sich mit Pfadnamen, der 
Assoziation von Ikonen zu Dateien und anderen sehr unange- 
nehmen Eigenschaften aufgesetzter grafischer Benutzeroberflächen 
wie Windows 3.0 herumzuschlagen. 


Der File-Manager stellt die Schnittstelle zwischen einem Programm 
und dem Teil des Betriebssystems dar, der sich mit der Datei- 
verwaltung beschäftigt; der File-Manager ermöglicht dem Pro- 
grammierer den Zugriff auf das Dateisystem des Macintosh. 
Soll eine Datei zum Lesen oder Schreiben geöffnet werden, so 
wird die Datei durch ihren Namen und durch eine Referenz auf 
das Directory, in dem sie sich befindet (das Parent-Directory), 
spezifiziert. Die Referenz auf das Parent-Directory erfolgt auf 
dem Macintosh über eine sogenannte "Working Directory"- 
Nummer. Diese Working-Directory-Nummer ist eine temporäre 
INTEGER-Zahl, die das Betriebssystem auf Anfrage generiert. 
Man bekommt diese Referenz-Nummer, sowie den Dateinamen 
von einer Funktion, die den in Abb. 5-1 dargestellten Standard- 
Öffnen-Dialog (SFGetFile) auf den Bildschirm bringt. In diesem 
von allen Macintosh-Applikationen verwendeten Dialog kann 
der Benutzer die Datei auswählen, die er öffnen möchte. Der 
Verweis auf eine Datei mittels eines Pfadnamens, wie dies bei- 
spielsweise bei MS-DOS üblich ist, ist auch auf dem Macintosh 
implementiert, sollte aber dem Benutzer verborgen bleiben. 


SF&etFile 


Abb. 5-1 

Der Standard-Öffnen- 
Dialog wird von allen 
Macintosh-Applikati- 
onen verwendet, damit 
der Benutzer eine Datei 
auswählen kann, die 
geöffnet werden soll. 
Dieser Dialog wird 
meistens als Reaktion 
auf die Auswahl des 
"Öffnen'-Menüpunktes 
aus dem 'Ablage'-Menü 
erzeugt. 


Für den Zugriff auf das Dateisystem des Macintosh stehen fol- 
gende Funktionen und Datenstrukturen zur Verfügung: 


Die Funktion SFGetFile präsentiert den in Abb. 5-1 gezeigten 
Dialog, in dem der Benutzer eine Datei auswählen kann, die er 
öffnen möchte. 
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pascal void SFGetFile ( 


Point where, 
Str255 *prompt, 
FileFilterProcPtr fileFilter, 
short numTypes, 
SFTypeList typelList, 
D1igHookProcPtr dlgHock, 
SFReply *reply); 


Der Parameter where gibt an, an welcher Stelle auf dem Bild- 
schirm der Dialog gezeichnet werden soll. 

Der Parameter prompt wird von den aktuellen Versionen des 
Betriebssystems ignoriert. Hier wird üblicherweise ein leerer String 
("\p") übergeben. 

Der Funktions-Pointer fileFilter kann ein Pointer auf eine Pro- 
zedur sein, die entscheidet, welche Dateien eines Ordners zur 
Auswahl zur Verfügung stehen. Viele Macintosh-Programme 
benutzen diese Möglichkeit dazu, dem Benutzer nur die Dateien 
zur Auswahl zu stellen, die das Programm auch öffnen kann. In 
der Regel werden Sie dieses Feature am Anfang Ihrer Macin- 
tosh-Programmierer-Karriere nicht benötigen, es wird daher hier 
nicht weiter beschrieben. Um dieses Feature nicht zu benutzen, 
übergibt man anstelle eines Funktions-Pointers den Wert NULL. 


Die nächsten beiden Parameter erlauben ebenfalls eine (wenn 
auch etwas gröbere) Selektion der Dateien, die dem Benutzer zur 
Verfügung stehen. In dem Parameter typeList kann man eine Reihe 
von File-Typen angeben, die dem Benutzer zur Verfügung ste- 
hen, numTypes gibt dabei die Anzahl der Dateitypen an, die in 
der Liste enthalten sind. Dem Benutzer werden in der Liste, die 
SFGetFile anzeigt, nur die Dateien zur Auswahl angeboten, die 
einen in SFTypeList enthaltenen File-Type haben. Wenn unser 
Programm beispielsweise nur Dateien vom Typ 'TEXT' lesen kann, 
so trägt man diesen Dateityp in die Liste SFTypeList ein und 
übergibt als Listenlänge die Zahl 1. Es erscheinen dann nur die 
Dateien zur Auswahl, die dem Dateityp 'TEXT' entsprechen. 
Der Parameter dlgHook stellt eine Möglichkeit dar, das Layout 
und die Funktionalität des Standard-Öffnen-Dialoges nach Be- 
lieben zu verändern. Viele Programme haben beispielsweise ein 
zusätzliches Pop-Up-Menü in ihrem Öffnen-Dialog, mit dem der 
Benutzer spezifizieren kann, welchen Dateityp er öffnen möch- 
te. Diese Möglichkeit, einen sogenannten "Custom Dialog" an- 
stelle des normalen Dialoges zu verwenden, werden Sie jedoch 
am Anfang noch nicht benötigen. Wir geben uns erst einmal mit 
dem ganz normalen Dialog zufrieden und übergeben anstelle 
von digHook den Wert NULL. 

Der letzte Parameter (reply) beinhaltet nach Beendigung des 
SFGetFile-Aufrufs die Auswahl bzw. die Antwort des Benutzers 
auf den von SFGetFile dargestellten Dialog. SFGetFile trägt in 
dem übergebenen SFReply die Antworten des Benutzers ein. Hat 
der Benutzer eine Datei ausgewählt und auf den Öffnen-Button 
geklickt, oder die Auswahl mittels Abbrechen terminiert, so be- 
inhaltet der struct, auf den reply zeigt, die entsprechenden 
Werte. 

Die Struktur eines SFReplys sieht wie folgt aus: 


l: struct SFReply { 

2: Boolean good; 

3: Boolean copy; 

4: oOSType fType; 
er short vRefNum; 
6 short version; 
7% Str63 fName; 
8: }; 


SFPutFile 


Abb. 5-2 

Der Standard-Sichern- 
Dialog wird verwendet, 
wenn der Benutzer eine 
Datei abspeichern will. 
In diesem Dialog kann 
er den Dateinamen 
eingeben, sowie die 
Position im Dateisystem 
spezifizieren. Die 
Funktion SFPutFile wird 
meistens als Reaktion 
auf die Auswahl des 
‘Sichern unter..." 
Menüpunktes aus dem 
"Ablage'-Menü 
aufgerufen. 


Der Boolean good gibt an, ob der Benutzer die Aktion abgebro- 
chen hat (false) oder ob er eine Datei ausgewählt und den Öff- 
nen-Button gedrückt hat (true). Ist der Wert dieses Feldes false, 
so sind alle anderen Felder ungültig. 

Der zweite Boolean (copy) wird zur Zeit noch nicht benutzt, und 
ist für zukünftige Erweiterungen des Betriebssystems reserviert. 
Das Feld fType gibt an, welchen File-Type die vom Benutzer 
ausgewählte Datei hat. Hier kann man erkennen, ob der Benut- 
zer z.B. eine Textdatei ("TEXT") oder eine Bilddatei ('PICT') aus- 
gewählt hat. 

In vRefNum bekommen wir die Referenz-Nummer auf das 
Directory, indem sich die ausgewählte Datei befindet. Diese Re- 
ferenz-Nummer muß beim Öffnen der Datei zusammen mit dem 
Dateinamen fName angegeben werden. 


Möchten Sie in Ihrem Programm die Möglichkeit des Abspei- 
cherns bieten, so verwenden Sie die Funktion SFPutFile. Diese 
Funktion präsentiert dem Benutzer einen Standard-Dialog zum 
Abspeichern einer Datei. SFPutFile arbeitet ähnlich wie SFGet- 
File, sie generiert jedoch den in Abb. 5-2 dargestellten Standard- 
Sichern-Dialog. 
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Das Feld where spezifiziert die Position des Dialogs (wie bei 
SFGetFile). 

Der String, auf welchen der Parameter prompt zeigt, erscheint im 
Dialog über dem Texteingabefeld für den Dateinamen. Hier 





übergibt man üblicherweise einen String wie "\pDatei sichern 
unter:" an. 

Mit dem Parameter origName kann man einen voreingestellten 
(Default) -Namen angeben, der zu Beginn des Dialogs in dem 
Texteingabefeld eingetragen ist. Üblicherweise gibt man hier ei- 
nen String wie "\pOhne Titel" (oder besser eine String-Resource) 
an. 

Der Parameter digHook dient dazu, einen Custom-Dialog zu 
generieren, reply gibt (wie bei SFGetFile) die Antworten des 
Benutzers zurück. 


Um eine Datei im Macintosh-Dateisystem anzulegen, verwen- 
det man die Funktion Create nachdem SFPutFile aufgerufen wurde. 


pascal OSErr Create (Str255 *fileName, 
short vRefNum, 
OSType creator, 
OSType fileType); 


Die Funktion erwartet zunächst einen Pascal-String als Datei- 
namen (fileName), bzw. eine Referenz-Nummer (vRefNum) auf 
das Directory in dem die neue Datei angelegt werden soll. Diese 
beiden Parameter werden von SFPutFile in dem reply-Parame- 
ter zurückgegeben, wir können sie beim Aufruf von Create ver- 
wenden. Der Parameter creator stellt den Creator-Type der zu 
eröffnenden Datei dar, fileType gibt den File-Type der anzu- 
legenden Datei an (beispielsweise 'TEXT'). 


Viele File-Manager-Funktionen haben einen Ergebniswert vom Typ 
OSErr. Ist dieser Ergebniswert (ein short) kleiner 0, so ist während der 
Ausführung der Routine ein Fehler aufgetreten. In diesem Fall wird 
der Fehler durch den Wert des zurückgegebenen OSErrs näher be- 
schrieben. Mögliche Fehlermeldungen sind zum Beispiel: "File not found” 
oder "File-System Full". 


Soll eine Datei zu Lesen oder Schreiben geöffnet werden, so wird 
die Funktion FSOpen verwendet. Diese Funktion wird in der Regel 
in Kombination mit SFPutFile und Create (beim Anlegen einer 
neuen Datei) oder mit SFGetFile (beim Öffnen einer bestehen- 
den Datei) verwendet. 


Create 


FSOpen 


FSWrite 





pascal OSErr FSOpen (Str255 *fileName, 
short vRefNum, 
short *refNum) ; 


Der Parameter fileName spezifiziert den Namen der zu öffnen- 
den Datei, vRefNum ist die Referenz auf den Ordner, in dem 
sich die die Datei befindet. FSOpen gibt in dem Parameter refNum 
eine temporäre Referenz-Nummer auf die geöffnete Datei zu- 
rück. Diese Referenz-Nummer wird bei allen anderen File-Ma- 
nager-Routinen angegeben, um dem File-Manager mitzuteilen, 
welche Datei bearbeitet werden soll. Durch die Verwendung dieser 
Referenz-Nummer ist es auf dem Macintosh möglich, bis zu 32768 
Dateien gleichzeitig zum Schreiben oder Lesen geöffnet zu ha- 
ben. Der File-Pointer (der Verweis auf die logische Position in- 
nerhalb der Datei) wird von FSOpen auf den Anfang der Datei 
gesetzt. Ein anschließender Lese- oder Schreibbefehl liest bzw. 
schreibt so automatisch vom Anfang der Datei an. 


Um Daten in eine geöffnete Datei zu schreiben, wird die Funk- 
tion FSWrite verwendet. Sie entspricht in ihrer Grundfunktiona- 
lität den Standard-I/O-Routinen anderer Betriebssysteme. 


pascal OSErr FSWrite ( short refNum, 
long *count, 
const void *buffPtr); 


FSWrite verlangt die Referenz-Nummer einer geöffneten Datei 
in dem Parameter refNum. Hier übergibt man üblicherweise die 
von FSOpen zurückgegebene temporäre Referenz-Nummer. Dieser 
Parameter spezifiziert die Datei, in die geschrieben werden soll. 
Der Parameter count spezifiziert die Anzahl der Bytes, die in die 
Datei geschrieben werden sollen. FSWrite wird hier die Adresse 
eines longs übergeben, damit die Funktion den Wert dieses longs 
ändern kann. FSWrite legt die Anzahl der wirklich herausge- 
schriebenen Bytes in diesem long ab. Normalerweise entspricht 
die Anzahl der geschriebenen Bytes natürlich der Anzahl der 
gewünschten Bytes (der Wert bleibt gleich). Wenn auf dem Me- 
dium, auf das geschrieben wird jedoch nicht genügend freier 
Speicherplatz existiert, so gibt FSWrite eine Fehlermeldung zu- 
rück und spezifiziert in der Variable auf die count zeigt, die Anzahl 





der Bytes, die noch auf das Medium gepaßt haben. Die Variable 
kann dann dazu verwendet werden, dem Benutzer in einem Dialog 
mitzuteilen, daß die Datei aus Platzmangel nicht auf das Volume 
geschrieben werden konnte, weil z.B. 530 Bytes fehlen. Eine sol- 
che Fehlermeldung wäre sicherlich sinnvoller (und hilfreicher) 
als "I/O Error". Der Pointer buffPtr zeigt auf die Daten, die in 
die Datei geschrieben werden sollen. Nach einem Aufruf von 
FSWrite steht der File-Pointer hinter dem zuletzt geschriebenen 
Zeichen. Auf diese Weise können mehrere Aufrufe von FSWrite 
hintereinander folgen, ohne daß der File-Pointer neu gesetzt 
werden muß; FSWrite hängt die zu schreibenden Daten automa- 
tisch hinter die zuletzt geschriebenen Daten an. 


FSRead stellt das Gegenstück zu FSWrite dar, diese Funktion ist 
für das Lesen von Daten aus einer Datei zuständig. 


pascal OSErr FSRead (short refNum, 
long *count, 
void *buffPtr); 


Bei einem Aufruf dieser Funktion werden die Daten aus der durch 
refNum spezifizierten, geöffneten Datei gelesen. Der Parameter 
count gibt wieder die Anzahl der gewünschten Bytes an, buffPtr 
zeigt auf die Adresse im RAM, an der die Daten abgelegt wer- 
den sollen. FSRead legt keinen Pointer oder Handle an. Daher muß 
buffPtr auf eine gültige Adresse zeigen. Dies kann eine globale 
oder lokale Variable (z.B. ein Array oder Struct) sein, oder auch 
die Adresse eines mit NewHandle alloziierten Blocks. FSRead 
verschiebt, wie FSWrite, den File-Pointer hinter das zuletzt gele- 
sene Zeichen. Daher kann man FSRead mehrere Male hinterein- 
ander aufrufen; FSRead liest die Datei Stück für Stück ein. 


Oft möchte man, bevor eine Datei mit Hilfe von FSRead eingelesen 
wird, wissen, wie lang die Datei ist. Zu diesem Zweck kann man 
die Funktion GetEOF verwenden. 


pascal OSErr GetEOF (short refNum, 
long *1logEOF); 


FSRead 


GetEOF 


GetFPos 


SetFPos 





GetEOF gibt die Länge der Datei in dem long zurück, dessen 
Adresse bei logEOF übergeben wird. Die Datei, auf die sich GetEOF 
bezieht, wird durch ihre Referenz-Nummer in refNum identifi- 
ziert. 


Wie schon beschrieben, ist eine Macintosh-Datei ein Byte-Stream, 
gesteuert von einem File-Pointer. Die aktuelle Position dieses File- 
Pointers kann mit Hilfe der folgenden Funktion abgefragt wer- 
den: 


pascal OSErr GetFPos ( short refNum, 
long *filePos); 


GetFPos gibt die Position des File-Pointers für die durch refNum 
spezifizierte Datei in der Variablen auf die filePos zeigt zurück. 
Der long, auf den filePos zeigt, wird dabei verändert, er ist (wie 
in den beiden vorangegangenen Funktionen) ein VAR-Parame- 
ter. 


Die Funktion SetFPos stellt das Gegenstück zu GetFPos dar. Mit 
Hilfe der Funktion SetFPos kann man die Position des File-Pointers 
manipulieren. Soll beispielsweise ab dem 300. Byte einer geöff- 
neten Datei gelesen werden, so benutzt man die Funktion SetFPos 
nach dem Öffnen der Datei, um den File-Pointer an die gewünschte 
Stelle zu bewegen. Anschließende FSRead-Aufrufe lesen dann 
ab dem 300. Byte. 


pascal OSErr SetFPos ( short refNum, 
short posMode, 
long posOff); 


Die betroffene Datei wird bei einem Aufruf von SetFPos (wie 
immer) durch den Parameter refNum spezifiziert. Der Überga- 
be-Parameter posMode beschreibt, in welcher Weise der letzte 
Parameter (posOff) interpretiert werden soll. Je nachdem wel- 
chen Wert man bei posMode übergibt, wird die neue Position des 
File-Pointers relativ zum Anfang oder Ende der Datei bzw. rela- 
tiv zur aktuellen Position des File-Pointers berechnet. An Stelle 
des Parameters posMode kann man die folgenden, vordefinierten 
Konstanten angeben: 


#define fsFromStart 1 // Vom Anfang der Datei 

#define fsFromLEOF 2 // Vom Ende 

#define fsfromMark 3 // Relativ zur aktuellen 
Position 


Der Parameter posOff spezifiziert, um wieviel Zeichen der File- 
Pointer verschoben werden soll. 


Ist die Bearbeitung einer Datei abgeschlossen, so schließt man 
die Datei mit Hilfe der Funktion FSClose. 


pascal OSErr FSClose (short refNum); 


Die zu schließende Datei wird durch den Parameter refNum 
spezifiziert. Nachdem diese Funktion aufgerufen wurde, ist die 
temporäre Referenz-Nummer refNum ungültig, sie kann nicht 
mehr als Verweis auf die Datei verwendet werden. 


Das Macintosh-Betriebssystem verwaltet einen Volume-Cache, 
dessen Größe vom Benutzer eingestellt werden kann. Dieser Cache 
puffert einen gewissen Teil des Input/Output - Streams für die 
an den Rechner angeschlossenen Volumes (Festplatten etc.). Der 
Vorteil dieses Caches ist klar: Finden (wie dies häufig geschieht) 
wiederholte Zugriffe auf denselben Teil einer Datei statt, so schreibt 
bzw. liest das Betriebssystem nur im Cache. Die I/O-Geschwin- 
digkeit kann mit dieser Technik bei einigen Vorgängen um ein 
Mehrfaches schneller werden. Es liegt aber auch eine gewisse 
Gefahr in dieser Cache-Technik. Speichert ein Programm seine 
Daten in einer Datei ab und stürzt kurz nach diesem Abspeichern 
ab, so kann es passieren, daß die (noch im Cache befindlichen) 
Daten verloren gehen und damit die geschriebene Datei unvoll- 
ständig ist. Dies geschieht dann, wenn der Absturz des Programms 
so fatal war, daß das gesamte System abstürzt, und der Macin- 
tosh neu gebootet werden muß. 

Um diesem, für den Benutzer sehr ärgerlichen Effekt vorzubeu- 
gen, sollte man nachdem man eine Datei geschrieben hat, den 
Volume-Cache mit Hilfe von FlushVol auf das Volume hinaus- 
schreiben. Stürzt das Programm nach diesem Aufruf ab, so blei- 
ben die Daten, die auf die Festplatte geschrieben wurden, erhal- 
ten. 


FSClose 


FlushVol 


FSDelete 





pascal OSErr FlushVol ( StringPtr volName, 
short vRefNum) ; 


Das Volume, dessen gepufferter Inhalt geschrieben werden soll, 
kann man bei einem Aufruf von FlushVol auf zwei verschiedene 
Weisen angeben: 


1. Durch den Namen des Volumes (Adresse eines Pascal-Strings) 
in volName. 

Diese Methode hat den Nachteil, daß man zunächst den Namen 
des Volumes, auf das geschrieben wurde, herausfinden muß. 
Normalerweise übergibt man anstelle von volName den Wert 
NULL, und verwendet die nachfolgende Möglichkeit. 


2. Das Volume kann durch die Volume-Reference-Number 
vRefNum spezifiziert werden. An dieser Stelle kann man auch 
die Referenz-Nummer eines Ordners angeben, wie man sie von 
SFPutFile oder SFGetFile zurückbekommt. Das System sucht sich 
dann automatisch das Volume heraus, zu dem der angegebene 
Ordner gehört. 


Soll eine Datei gelöscht werden, so wird die Funktion FSDelete 
verwendet. 


pascal OSErr FSDelete ( Str255 *fileName, 
short vRefNum) ; 


Die zu löschende Datei muß durch ihren Namen im Parameter 
fileName und durch die Referenz-Nummer des Ordners, in 
welchem sie sich befindet, spezifiziert werden (vRefNum). 


Die folgende Funktion stellt zunächst einen Standard-Sichern- 
Dialog auf dem Bildschirm dar, eröffnet eine neue Textdatei un- 
ter dem Namen, den der Benutzer eingetragen hat und schreibt 
dann einen String in diese Datei: 


1: void SaveMyText (void) 
2: { 
3% SFReply reply; 
4: short countBytes, fileRefNum; 
98 OSErr err; 
6: Point where; 
Fe 
8: where.h = where.v = 100; 
9: SFPutFile (where, "\pSichern unter:", 
"\pOhne Titel", NULL, &reply); 
10: if (reply.good) 
11: { 
12: err = Create (reply.fName, 
reply.vRefNum, 'BLÖD', "TEXT'); 
13: err = FSOpen (reply.fName, 
. reply.vRefNum, &fileRefNunm); 
14: countBytes = 4; 
15: err = FSWrite (fileRefNum, 
&countBytes, "Text"); 
16: err = FSClose (fileRefNum); 
2 } 
18% ;) 


Die Funktion beginnt damit, den üblichen Standard-Sichern-Dialog 
mit Hilfe der Funktion SFPutFile zu zeigen. Der Point where wird 
auf (100, 100) gesetzt, SFPutFile zeichnet den Dialog an dieser 
Position auf den Bildschirm. Der String "\pSichern unter:" er- 
scheint in dem Sichern-Dialog über der Liste der Directories. Da 
wir keinen Custom-Dialog wollen, übergeben wir an der Stelle 
von digHook NULL. Als letzter Parameter wird die Adresse un- 
serer lokalen Variablen reply übergeben, so daß SFPutFile die 
Antworten des Benutzers in diesem struct ablegen kann. 

In Zeile 10 wird abgefragt, ob der Benutzer den Abbrechen-Button 
gedrückt hat, oder ob er die Datei speichern möchte. Zeile 12 legt 
dann mit Create unter Verwendung der Benutzereingaben die 
neue Datei an. Der Dateiname wurde vom Benutzer eingegeben 
und wir bekommen ihn in reply.fName zurück. Das vom Be- 
nutzer ausgewählte Directory (in dem die Datei abgespeichert 
werden soll) gibt SFReply in reply.vRefNum zurück. Diese 
vRefNum ist die temporäre Referenz-Nummer (Working- 
Directory-Reference-Number) des Directorys, in dem die Datei 
abgespeichert werden soll. Als Creator-Type übergeben wir hier 


Die Funktion 
SaveMyText legt eine 
neue Datei an und 
schreibt einen String in 
diese Datei. 


Wenn eine Datei 
angelegt wird, sollte 
sichergestellt werden, 
daß keine andere Datei 
mit gleichem Namen in 
dem Directory existiert. 





eine Zeichenkombination, die sonst sicherlich nicht verwendet 
wird; auf diese Weise vermeiden wir Konflikte mit den Creator- 
Types anderer Applikationen. Da wir eine Textdatei anlegen 
wollen, wird als letzter Parameter der File-Type 'TEXT' überge- 
ben. Create legt also eine Textdatei an, und alle Textverarbei- 
tungsprogramme werden die Datei lesen können. 

Nun haben wir eine neue, leere Textdatei. Um etwas hinein- 
schreiben zu können, müssen wir die neue Datei zum Schreiben 
öffnen. Die geschieht in Zeile 13 mit dem Aufruf von FSOpen. 
Dieser Funktion spezifizieren wir unter Verwendung derselben 
Parameter wie bei Create die zu öffnende Datei. Wir geben den 
Dateinamen und die Referenz-Nummer des Directorys an, in 
welchem sich unsere neu eröffnete Datei befindet. Als letzten 
Parameter geben wir FSOpen die Adresse unserer lokalen Vari- 
ablen fileRefNum. FSOpen ändert den Inhalt dieser Variablen 
in eine temporäre Referenz-Nummer, die mit der Datei assozi- 
iert wird. 

Diese File-Referenz-Nummer wird in Zeile 14 bei FSWrite be- 
nutzt, um die Datei, in die unser String geschrieben werden soll, 
zu spezifizieren. FSWrite bekommt als zweiten Parameter die 
Adresse unserer Variablen countBytes, die die Anzahl der zu 
schreibenden Zeichen enthält. Der letzte Parameter schließlich 
entspricht der Adresse der zu schreibenden Daten, in diesem Fall 
eines Strings. Der C-Compiler generiert an dieser Stelle automa-. 
tisch die Adresse unseres Strings. 

Jetzt haben wir eine neu eröffnete Datei, die einen String enthält. 
Wir brauchen die Datei nur noch zu schließen, und Textverar- 
beitungsprogramme können die Datei lesen. Geschlossen wird 
die Datei mit Hilfe von FSClose, die zu schließende Datei wird 
durch unsere File-Referenz-Nummer spezifiziert. 


Das kleine Beispiel hat noch zwei Probleme: 


1. Soll eine Datei überschrieben werden (der Benutzer hat einen 
Namen angegeben, der in dem Ordner bereits existiert), so tut 
Create überhaupt nichts und FSOpen öffnet die Datei. Wir 
schreiben dann munter in die Datei hinein und schließen sie wieder. 
Wenn die Datei eine lange Textdatei war, so ändern wir nur die 
ersten 4 Buchstaben, der Rest der Datei bleibt bestehen. Die Lö- 





sung für dieses nicht ganz saubere Verhalten unserer Routine 
ist, eine bestehende Datei zunächst zu löschen, bevor wir eine 
neue anlegen. 


2. Nach dem erfolgreichen Schreiben unserer Datei fehlt in dem 
Beispiel noch der Aufruf von FlushVol, um den Inhalt des Vo- 


lume-Caches auf das Volume zu schreiben. 


Die Verbesserte Version der Beispielroutine: 


1: void SaveMyText (void) 

2: { 

3 SFReply reply; 

4: short countBytes, fileRefNum; 
5% OSErr err; 

6: Point where; 

7 

8 where.h = where.v = 100; 

9 SFPutFile (where, "\pSichern unter:", 


"\pOhne Titel", NULL, &reply); 
170% if (reply.good) 


11% { 

12: err = FSDelete (reply.fName, 
reply.vRefNum) ; 

13: err = Create (reply.fName, 
reply.vRefNum, 'BLÖD', '"TEXT'); 

14: err = FSOpen (reply.fName, 
reply.vRefNum, &fileRefNum); 

15: countBytes = 4; 

16: err = FSWrite (fileRefNum, 
&countBytes, "Text"); 

17% err = FSClose (fileRefNum) ; 

18: err = FlushVol (NULL, reply.vRefNum); 

19: } 

20: } 


Die verbesserte Version der Routine stellt in Zeile 12 mit dem 
Aufruf von FSDelete sicher, daß die Datei, die in Zeile 13 ange- 
legt wird, noch nicht existiert. Eventuelle Fehlermeldungen von 
FSDelete können hier ignoriert werden. 

Der Aufruf von FlushVol in Zeile 18 stellt sicher, daß die ge- 
schriebenen Daten auch wirklich auf das Volume herausge- 
schrieben werden, und nicht mehr im Volume-Cache gepuffert 


Diese Version der 
Routine löscht zunächst 
eine eventuell vorhande- 
ne Datei, welche 
denselben Namen wie 
die anzulegende Datei 
hat. Auf diese Weise 
wird Problemen beim 
Abspeichern vorge- 
beugt. Weiterhin sorgt 
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der Volume-Cache 
(RAM) nach dem 
Abspeichern auf die 
Festplatte geschrieben 
wird. 
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dann in den neuen 
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werden. Sollte unser Programm im weiteren Verlauf abstürzen, 
so wäre die angelegte Datei in Ordnung. 


Ein paar weitergehende Anmerkungen zu diesem Beispiel: 

Die Funktion ist immer noch nicht perfekt. So werden beispiels- 
weise keinerlei Fehlermeldungen der File-Manager-Funktionen 
beachtet. Würde unsere Datei beispielsweise nicht mehr auf das 
Volume passen, so könnten wir den Benutzer nicht davon infor- 
mieren, da die Funktion sämtliche Hilferufe des Macintosh- 
Betriebssystems ignoriert. Es ist absolut unerläßlich, daß ein 
Macintosh-Programm sämtliche Fehlermeldungen von System- 
Funktionen abfragt, und auch entsprechend reagiert. In dem 
beschriebenen Problemfall würden Datenverluste entstehen, in 
anderen Fällen kann solche Ignoranz auch zu Abstürzen des 
Gesamtsystems führen. In diesem (und anderen Beispielen) wird 
auf eine komplette Fehlerbehandlung verzichtet, um die Über- 
sichtlichkeit der Beispiele zu erhalten. 


Die nachfolgende Beispielfunktion liest den Inhalt einer Text- 
datei in einen neu angelegen Handle und gibt diesen als Er- 
gebniswert zurück: 


1: Handle LoadText (void) 

2: 4 

3 SFReply reply; 

4: SFTypeList typeList; 
5: short fileRefNum; 
6: long countBytes; 
7 OSErr err; 

8: Point where; 

9: Handle theTextHdl; 
10: 

11: where.h = where.v = 100; 
12: typeList[0] = 'TEXT'; 
13: theTextHdl = NULL; 
14: SFGetFile (where, "\p", NULL, 1, 


typeList, &reply); 
5% if (reply.good) 
16: { 
17: err = FSOpen (reply.fName, 
reply.vRefNum, &fileRefNum); 
18: err = GetEOF (fileRefNum, &countBytes); 





1:9: theTextHdl = NewHandle (countBytes); 


20: err = FSRead (fileRefNum, &countBytes, 
*theTextHdl ); 

21: err = FSClose (fileRefNun) ; 

22: } 

2:33 return theTextHdl; 

24: } 


Die Funktion sorgt zunächst mit einem Aufruf von SFGetFile dafür, 
daß dem Benutzer der gewohnte Standard-Öffnen-Dialog gezeigt 
wird. Der von SFGetFile erzeugte Dialog erscheint bei den Ko- 
ordianten (100, 100), da der Point where auf diese Werte gesetzt 
wurde. Der leere String "\p" wird von SFGetFile in den aktuel- 
len Versionen des Betriebssystems ignoriert. Die Übergabe des 
Wertes NULL anstelle des File-Filter-Proc-Ptrs teilt SFGetFile mit, 
daß wir keine File-Filter-Function haben möchten. Die nächsten 
beiden Parameter beschäftigen sich mit der Auswahl an Datei- 
Typen, die dem Benutzer zur Auswahl gestellt werden. Da die 
Funktion zum Lesen von Textdateien implementiert ist, sollten 
wir dem Benutzer nur Textdateien zur Auswahl stellen. Daher 
übergeben wir als Anzahl der File-Types den Wert 1 und setzen 
in Zeile 12 daserste Feld des Arrays auf den Text-File-Type 'TEXT'. 
Nachdem der Benutzer eine Datei ausgewählt hat, befindet sich 
die Auswahl in reply. In Zeile 15 wird zunächst noch einmal 
abgefragt, ob der Benutzer die Datei auch wirklich öffnen woll- 
te, oder ober den "Abbrechen"-Button gedrückt hat. Zeile 17 öff- 
net die ausgewählte Datei unter Verwendung der in reply ab- 
gelegten Antworten des Benutzers. 

In Zeile 18 wird nun zunächst mit Hilfe von GetEOF gefragt, wie 
lang die Textdatei ist, um in Zeile 19 einen Handle von der gefor- 
derten Größe anzulegen. Der Aufruf von FSRead in Zeile 20 liest 
die Textdatei in den angelegten Handle. Die Datei, aus der gele- 
sen werden soll, wird durch die von FSOpen zurückgegebene File- 
Reference-Number spezifiziert, die Anzahl der zu lesenden Bytes 
in countBytes. Zum Schluß wird die Datei geschlossen und der 
angelegte Handle als Ergebniswert zurückgegeben. 


Auch diese Beispielfunktion ist nicht perfekt: In Zeile 20 sollte 
der Ergebniswert von NewHandle auf NULL abgefragt werden, 
denn es könnte ja sein, daß unser Speicherbereich nicht mehr 


Immer, wenn ein 
Macintosh-Programm 
Speicherbereiche anlegt, 
sollte überprüft werden, 
ob die Alloziierung 
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genügend Platz hat, um den Handle aufzunehmen. Falls die 
Funktion NewHandle NULL zurückgibt, sollte eine Fehlerbe- 
handlungsroutine aufgerufen werden, die dem Benutzer mitteilt, 
daß nicht mehr genügend Speicherplatz vorhanden ist, um die 
Datei zu öffnen. Auf jeden Fall sollte der FSRead-Aufruf in Zeile 
20 unterlassen werden, da bei diesem Aufruf der dereferenzierte 
Wert von theText übergeben wird. Wenn theText NULL ist, wird 
dabei der Inhalt der Speicherstelle 0 übergeben. FSRead denkt 
dann, daß es sich bei diesem Wert um eine gültige Adresse han- 
delt, und schreibt die zu lesenden Daten dorthin. Dies würde 
mit hoher Wahrscheinlichkeit zu einen Systemabsturz führen. 


Übrigens: Der Handle theText braucht hier nicht gelockt zu werden, 
obwohl wir einen dereferenzierten Handle übergeben! Dies kommt daher, 
daß die Funktion FSRead keinen temporären Speicher anlegt. Die 
ToolBox-Funktionen, die während ihrer Ausführung Speicher anlegen, 
sind im "Inside Macintosh" Appendix B "Routines that may move or 
purge memory" enthalten. 





Dieses Kapitel stellt das Konzept der Resources vor. Hier wird 
das neuartige Verfahren der Trennung von Programmdaten und 
Programmcode vorgestellt. Der Konzeption folgt dann die 
Anwendung des Resource-Managers, der den Zugriff auf die 
Resources ermöglicht. 


Apple hat mit Einführung des Macintosh-Betriebssystems ein neues 
Konzept der Datenverwaltung in einem Programm eingeführt, 
die sogenannten "Resources". Eine Macintosh-Datei, und damit 
auch ein Programm, besteht immer aus zwei Datei-Zweigen. 
Einerseits besteht eine Macintosh-Datei aus dem sogenannten 
"Data Fork", auf den mit Hilfe der oben beschriebenen File-Ma- 
nager-Routinen zugegriffen werden kann. Andererseits erlaubt 
der sogenannte "Resource Manager" den Zugriff auf einen zwei- 
ten Fork (Zweig) der Datei: den "Resource Fork". Für den Benutzer 
erscheinen beide Datei-Zweige als eine Datei, für uns als Pro- 
grammierer besteht jedoch eine eindeutige Trennung der beiden 
Datei-Zweige. Der Data-Fork wird, wie dies im vorangegangen 
Kapitel beschrieben wurde zum Speichern von Daten verwen- 
det. So werden beispielsweise in einem Text-Dokument die Zei- 
chen mit Hilfe des File-Managers im Data-Fork der Textdatei 
abgelegt. Bei einem Programm, welches ja auch eine Datei ist, 
sieht das etwas anders aus. Eine Programmdatei besteht haupt- 
sächlich aus dem Resource-Zweig. Der Resource-Zweig einer Datei 
ist auf unterer Ebene ebenfalls ein Byte-Stream, gesteuert von 
einem File-Pointer. Auf Resource-Manager-Ebene ist der Resource- 
Zweigjedoch eine Art hierarchischer Datei mit""Unterabteilungen". 


Abb. 6-1 

Die Unterteilung einer 
Macintosh-Datei in 
Resource- und Data- 
Fork 


Das Macintosh-System 
wird in zahlreichen 
Sprachen ausgeliefert. 
Um erfolgreich in die 
Welt der Macintosh- 
Programme zu starten, 
sollte das Programm 
der jeweiligen Landes- 
sprache angepaßt 
werden. Um diesen 
Prozeß zu vereinfachen, 
sollten sämtliche 
Programmeldungen und 
Dialog-Layouts mit Hilfe 
von Resources definiert 
werden. 


Van 


File 


Resource Data 
Jg | 
MENU 
129 
CODE 





Die Ordnung innerhalb des Resource-Forks wird mit Schlüsseln 
von vier Zeichen (Resource-Type) und innerhalb eines Resource- 
Types mit einer INTEGER-Identifikations-Nummer (Resource- 
ID) implementiert. Die hierarchische Unterteilung des Resource- 
Forks wird in Abb. 6-1 gezeigt. Macintosh-Programme bestehen 
aus einer Vielzahl von Resources, in denen Programmeldungen, 
Dialog-Layouts, der ausführbare Programm-Code und andere 
Informationen abgelegt sind. 

Das Konzept der Resources hat viele Gründe und Vorteile: Zu- 
nächst erlaubt es beispielsweise die Trennung des Programm- 
codes von den Meldungen, die dem Benutzer präsentiert werden. 
Anstelle von String-Konstanten im Quelltext werden bei der 
Programmierung des Macintosh üblicherweise alle Strings in 
Resources gespeichert. Der Vorteil dieser Trennung von Quelltext 
und Strings liegt u.a. darin, daß man mit Hilfe von ResEdit (einem 
Programmierer-Werkzeug) auf den Resource-Fork einer Appli- 
kation zugreifen kann. ResEdit ist ein grafischer Resource-Editor, 
mit dem man Resources anlegen, ändern und auch löschen kann. 
Mit Hilfe von ResEdit ist es beispielsweise möglich, die in Re- 
sources enthaltenen Strings zu ändern, ohne den Quelltext des 
Programms zu besitzen. Dadurch wird es möglich, die Lokali- 
sierung eines Programms (z.B. die Übersetzung ins Französische) 
von einem spezialisierten Übersetzungsbüro erledigen zu lassen, 
ohne daß das Programm anschließend neu compiliert werden 
muß. Im Resource-Zweig einer Applikation sind weiterhin auch 
die Layouts von Dialogen enthalten, einer weiteren Komponen- 
te, welche lokalisiert werden muß; wenn sich beispielsweise ein 
Button namens "Cancel" bei der Lokalisierung in "Abbrechen" 
ändert, so ist es wahrscheinlich, daß die Größe und eventuell 





auch die Position des Buttons geändert werden muß. Diese, bei 
der Lokalisierung eines Programms notwendigen Modifikatio- 
nen, können ebenfalls mit dem Resource-Editor ResEdit von dem 
Übersetzungsbüro durchgeführt werden. Da das veränderte 
Programm mit Hilfe des Resource-Managers auf die Resources 
zugreift, greift es nach der Änderung einer String-Resource auf 
die geänderte Resource zu und stellt den (jetzt vielleicht franzö- 
sischen Text) auf dem Bildschirm dar. Ein Macintosh-Programm 
ist so flexibel zu programmieren, daß es sprachunabhängig und 
damit universell einsetzbar bzw. lokalisierbar ist. Die Verwen- 
dung von String-Konstanten (die in den Einführungsbeispielen 
teilweise verwendet wird) sollte bei der Implementierung eines 
kommerziellen Programms unbedingt vermieden werden. Möchte 
ein Programm auf eine Resource (z.B. String-Resource) zugrei- 
fen, so übergibt man als Schlüssel zu dieser Resource den Re- 
source-Type und die Resource-ID. Für das Beispiel einer String- 
Resource wäre dies der Resource-Type 'STR ' und die entspre- 
chende Identifikations-Nummer der Resource (z.B. 128). Der 
Resource-Manager sucht dann innerhalb der 'STR '-Resourcesnach 
einer Resource mit der ID 128 und lädt diese in einen neu ange- 
legten relocatable-Block im Speicherbereich der Applikation. Der 
Handle auf diese geladene String-Resource wird an das Programm 
zurückgegeben. 

Ein weiteres Beispiel für Resources sind die 'CODE'-Resources, 
so enthält der Resource-Zweig einer Applikation beispielsweise 
unter dem Schlüssel der 'CODE'-Resources den ausführbaren 
Maschinencode (Object-Code). 

Oft greift ein Programm quasi indirekt auf den Resource-Mana- 
ger bzw. auf die Resources zu. Das Darstellen eines Dialoges, 
welches über den Dialog-Manager geschieht, funktioniert bei- 
spielsweise so, daß man dem Dialog-Manager die Resource-ID 
eines darzustellenden Dialogs übergibt. Der Dialog-Manager ruft 
dann den Resource-Manager mit der Bitte auf, aus den Dialog- 
Resources (DLOGs) die Dialog-Resource mit der entsprechen- 
den Resource-ID zu laden. Der Resource-Manager lädt die ent- 
sprechende Dialog-Beschreibungs-Resource in den Speicherbereich 
der Applikation und gibt dem Dialog-Manager einen Handle auf 
diese nun im RAM befindliche Resource zurück. Der Dialog- 
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Manager benutzt dann die in diesem Handle befindlichen Dia- 
log-Beschreibungen, um den Dialog auf dem Bildschirm zu bringen. 


Zu einigen Zwecken spricht man den Resource-Manager auch 
direkt an. Wenn beispielsweise eine String-Resource geladen 
werden soll, so muß man direkt mit dem Resource-Manager zu- 
sammenarbeiten. Sollen Resources zum Resource-Fork unserer 
Applikation hinzugefügt oder geändert werden (Beispiel: Vor- 
einstellungen/Preferences), so ruft man ebenfalls Resource- 
Manager-Routinen auf, die für diesen Zweck implementiert 
worden sind. 


Rund um die Resources stehen ein paar nützliche Funktionen 
zur Verfügung: 


Möchte man eine Resource laden, so benutzt man die Routine 
GetlResource. 


pascal Handle GetlResource ( ResType theType, 
short thelID); 


GetlResource sucht die Resource mit der Resource-ID theID 
innerhalb der Resources vom Typ theType. Get1Resource legt dann 
einen Handle mit der Größe der Resource im Speicherbereich 
der Applikation an und gibt den Handle als Ergebniswert zurück. 
Konnte die Resource nicht gefunden werden, oder ist nicht mehr 
genügend freier Speicherplatz im Speicherbereich der Applika- 
tion vorhanden, um den Handle anzulegen, so gibt Get1Resource 
NULL zurück. Die Fehler-Nummer (Beschreibung des Fehlers 
wie beim File-Manager) bekommt man in diesem Fall, indem man 
die Funktion ResError aufruft. Es ist unbedingt notwendig, daß 
der Ergebniswert von GetlResource auf NULL abgefragt wird, 
da nachfolgende Programmteile, die mit dem Handle arbeiten 





sollen, eventuell einen Absturz verursachen können, wenn sie 
auf die von dem Handle verwalteten Daten zugreifen wollen, 
und der Handle NULL ist. 

GetlResource trägt in einer vom Resource-Manager verwalteten 
Tablelle ein, daß die Resource bereits geladen worden ist, und 
merkt sich in dieser Tabelle auch den Handle auf die geladene 
Resource. Dies bewirkt, daß ein Aufruf von GetlResource für 
eine bereits geladene Resource nur den Handle auf die bereits 
geladene Resource zurückgibt. Get1Resource legt also keinen 
zweiten Handle an, wenn diese Funktion zweimal hintereinan- 
der für dieselbe Resource aufgerufen wird. 


Mit Hilfe von AddResource kann man eine neue Resource im 
Resource-Fork der Applikation anlegen. 


pascal void AddResource ( Handle theResource, 
ResType theType, 
short thelD, 
Str255 *name); 


Um eine neue Resource anzulegen, ist es notwendig, die Daten, 
die in der neuen Resource abgelegt werden sollen, mit einem 
Handle zu verwalten, da die Funktion AddResource in dem Pa- 
rameter theResource einen Handle auf die Daten erwartet, die 
als Resource abgespeichert werden sollen. Der ParametertheType 
gibt an, welchen Resource-Type die neu anzulegende Resource 
haben soll. Hier ist es wichtig, daß man entweder standardisier- 
te Resource-Typen, wie 'STR ' (String-Resource) oder MENU’ 
(Menü-Resource) verwendet und sich dann auch an die mit die- 
sem Resource-Type assoziierten Datenstrukturen hält, oder daß 
man einen eigenen, privaten Resource-Type benutzt. 

Innerhalb der mit dem Parameter theType spezifizierten Resource- 
Typen wird die neue Resource unter der Identifikationsnummer 
theID abgelegt. Der letzte Parameter (name) kann einen String 
enthalten, der der Resource einen Namen gibt. Diese Vergabe 
von Namen für Resources ist einerseits zum besseren Verständ- 
nis zu verwenden, wenn man sich den Resource-Fork der Appli- 
kation mit Hilfe von ResEdit ansieht (dort kann man neben den 
Resource-ID einer Resource auch den Namen einer Resource 
sehen). Andererseits gibt es auch Funktionen innerhalb des 


AddResource 





Unique1lD 


RmveResource 


Resource-Managers, die den Zugriff auf eine Resource mit Hilfe 
des Resource-Types und des Resource-Namens ermöglichen. Der 
Resource-Name stellt bei dem Zugriff eine Alternative zur 
Resource-ID dar. 

Wenn man z.B. eine Preference-Resource anlegen möchte, dann 
sollte man dazu einen privaten Resource-Type verwenden, da 
diese Datenstruktur wahrscheinlich keiner standardisierten 
Datenstruktur entsprechen wird. Ein privater Resource-Type sollte 
nur Uppercase-Letters (Großbuchstaben) enthalten, da alle 
Lowercase-Letters von Apple reserviert sind. Zusätzlich sollte 
man sicherstellen, daß der verwendete Resource-Type nicht ei- 
nem der vielen vordefinierten Resource-Typen entspricht. Dies 
kann man mit Hilfe der Dokumentation und bestimmter Datei- 
en der verwendeten Entwicklungsumgebung tun. Bei MPW 
(Macintosh Programmers Workshop), der Apple-eigenen 
Entwicklungsumgebung, sind die vordefinierten Resource-Typen 
in der Datei "MPW:Interfaces:RIncludes:Types.r" enthalten. 


Ein weiterer Punkt, der beim Anlegen einer Resource beachtet 
werden muß, ist die Tatsache, daß es innerhalb eines bestimm- 
ten Resource-Types nur eindeutige IDs geben darf; zwei Resources 
mit derselben ID und demselben Resource-Type sind unzuläs- 
sig. Leider arbeitet der Resource-Manager in recht undefinierter 
Weise, wenn man versucht, eine Resource anzulegen, deren ID 
innerhalb des Resource-Types bereits existiert. 

Daher gibt es die Funktion namens UniquellD: 


pascal short UniquelID (ResType theType); 


UniquellD gibt für den angegebenen Resource-Type eine ID zu- 
rück, die von keiner anderen Resource verwendet wird. Diese 
Funktion wird oft beim Anlegen einer neuen Resource verwen- 
det, um sicherzustellen, daß keine ID-Konflikte entstehen. 


Wenn man eine Resource löschen möchte, so steht die Funktion 
RmveResource zur Verfügung. Zunächst muß die zu löschende 
Resource mit Hilfe von Getl1Resource geladen werden. 


pascal void RmveResource (Handle theResource); 





Den von GetlResource zurückgegebenen Handle auf die (nun 
geladene Resource) gibt man anstelle des Parameters theResource 
an. Die Resource wird dann aus dem Resource-Fork der Datei 
(normalerweise dem Programm) gelöscht. Beider Benutzung von 
RmveResource ist zu beachten, daß nur die Resource gelöscht 
wird, der Handle aber nicht freigegeben (disposed) wird. 
RmveResource löscht lediglich den Eintrag in der Resource-Map 
der Datei. Soll der Speicherplatz im Speicherbereich freigegeben 
werden, so muß man zusätzlich noch die Memory-Manager- 
Funktion DisposeHandle aufrufen. 


Wenn eine Resource geladen werden soll und die Daten dieser 
geladenen Resource eventuell verändert werden, dann verwen- 
det man in der Regel die Funktion DetachResource, um Seiten- 
effekte dieser Änderungen zu vermeiden. DetachResource nimmt 
die geladene Resource dem Resource-Manager weg. Das bedeutet, 
daß er beim nächsten Aufruf von GetlResource einen neuen Handle 
anlegen und die Resource in den Handle lesen wird. Auf diese 
Weise wird vermieden, daß andere Programmteile auf die geän- 
derten Daten der Resource zugreifen, sondern stattdessen ihre 
eigene Kopie der Daten bekommen. 


pascal void DetachResource (Handle theResource); 


DetachResource löscht den Eintrag der Resource theResource in 
der vom Resource-Manager verwalteten Resource-Table. Wird 
das nächste mal Get1Resource aufgerufen, so denkt der Resource- 
Manager, daß die Resource noch nicht geladen ist, legt einen neuen 
Handle an und liest die Daten erneut von der Festplatte bzw. 
vom Resource-Fork der Applikation. 


Da der Resource-Manager seine geladenen Resources kennt, kann 
man ihm sagen, daß sich der Inhalt einer bestimmten, geladenen 
Resource geändert hat, und daß diese Resource bei Beendigung 
der Applikation vom RAM in den Resource-Fork der Applikation 
zurückgeschrieben werden soll. Dieses Verhalten ist z.B. beim 
Ändern der Preferences sehr nützlich. 


pascal void ChangedResource ( 
Handle theResource); 
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Hat der Benutzer die Voreinstellungen geändert, so reflektieren 
wir dies, indem der Inhalt der Preference-Resource im RAM 
geändert wird, und anschließend ChangedResource für diese 
geladene Resource aufgerufen wird. Wenn der Benutzer unser 
Programm beendet, so wird die geänderte Resource vom Resource- 
Manager automatisch in den Resource-Fork der Applikation 
zurückgeschrieben (falls vorher kein Absturz passiert). 


Wenn man sich nicht damit zufrieden geben möchte, daß eine 
geänderte Resource erst bei Beendigung des Programms in den 
Resource-Fork der Applikation zurückgeschrieben wird 
(ChangedResource), so kann man die Funktion WriteResource 
aufrufen. Die geladene Resource theResource wird dann sofort 
in den Resource-Fork der Applikation zurückgeschrieben. 


pascal void WriteResource (Handle theResource); 


CurResFile gibt die Referenznummer des Resource-Forks der 
aktuellen Datei zurück. Normalerweise entspricht diese Referenz- 
nummer dem Resource-Fork unserer Applikation. Wir können 
also CurResFile aufrufen, um eine Referenznummer auf den Re- 
source-Fork unserer Applikation zu bekommen. 


pascal short CurResFile (void); 


Hat man mehrere Resources geändert, die auch sofort zurück- 
geschrieben werden sollen, so ruft man in der Regel für jede ge- 
änderte Resource ChangedResource auf und benutzt danach die 
Funktion UpdateResFile in Kombination mit CurResFile. 


pascal void UpdateResFile (short refNum); 


UpdateResfFile schreibt alle durch ChangedResource als geändert 
markierten Resources in den durch refNum spezifizierten 
Resource-Fork zurück. Diese Funktion verlangt dabei, ähnlich 
wie die File--Manager-Routinen, eine File-Reference-Nummer auf 
den Resource-Fork der Datei, die aktualisiert werden soll. Da 
der Resource-Fork unserer Applikation während der Ausführung 
des Programms ständig geöffnet ist (es müssen ja eventuell 'CODE'- 
Resources nachgeladen werden) brauchen wir den Resource-Fork 





unserer Applikation nicht erst "per Hand" zu öffnen, sondern 
können uns die File-Referenz-Nummer unseres Resource-Forks 
mit Hilfe von CurResFile geben lassen. 


Es folgt ein kleines Beispiel für das Laden einer String-Resource 
aus dem Resource-Fork der Applikation: 


1: void DrawResourceString (void) 
ZEN 

4: StringHandle ourStringHandle; 
5: 

6 


ourStringHandle = (StringHandle) 
GetlResource ('STR ', 128); 
HLock ((Handle) ourStringHandle); 
DrawString (*ourStringHandle); 
HUnlock ((Handle) ourStringHandle); 


Oo 0 ao 


Die Funktion DrawResourceString zeichnet einen String, der aus 
einer Resource geladen wurde. Zum Laden der Resource wird 
die Funktion Get1Resource verwendet. Wir laden hier die String- 
Resource (STR ') mit der ID 128. Der Resource-Manager wird 
einen Handle von der benötigten Größe anlegen (256 Bytes) und 
den Inhalt der Resource (unseren String) in den angelegten Handle 
einlesen. Wir bekommen einen Handle auf die geladene Resource 
als Ergebniswert geliefert. Da wir wissen, daß Get1Resource 
einen Handle auf einen String liefert, verwenden wir in Zeile 6 
Type-Casting um den Handle in einen StringHandle zu verwan- 
deln. Wie im Abschnitt über den Memory-Manager besprochen, 
haben wir ein Problem, wenn wir die Adresse einer mit einem 
Handle verwalteten Datenstruktur an eine Funktion übergeben, 
die temporär Speicher alloziiert. Hier haben wir wieder einmal 
diesen Problemfall: DrawString alloziiert temporär Speicher und 
verlangt die Adresse eines Pascal-Strings als Parameter. Da wir 
unseren String mit einem Handle verwalten, haben wir den 
beschriebenen klassischen Problemfall. DrawString würde 
während der Ausführung eventuell unseren Handle verschie- 
ben und damit undefinierte Zeichen auf den Bildschirm brin- 
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Die Ergebniswerte von 
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gen. Die Lösung des Problems ist hier wieder das temporäre 
"Locken" des Handles mittels HLock, bzw. das "Unlocken" des 
Handles mit HUnlock. 

Ein weiteres Problem unseres kleinen Beispiel-Programmes ist 
in der bisherigen Version noch nicht gelöst: Hat der Resource- 
Manager beim Anlegen des Handles im Speicherbereich unserer 
Applikation nicht mehr genügen Platz, oder existiert die gewün- 
schte Resource nicht, so gibt er den Wert NULL zurück. Da wir 
den Ergebniswert von Get1Resource nicht abfragen, würden wir 
in Zeile 7 versuchen, einen NULL-Handle zu locken, bzw. über- 
geben in Zeile 8 den dereferenzierten Wert von NULL. Beides ist 
ein recht ungesundes Verhalten. So würde DrawString in die- 
sem Fall entweder undefinierte Zeichen auf den Bildschirm ma- 
len, oder aufgrund des Zugriffes auf eine nicht vorhandene 
Speicherstelle mit "Bus-Error" abstürzen. Man sollte daher den 
Ergebniswert der Funktion Get1Resource, wie jeden Ergebnis- 
wert einer Routine, die Speicher alloziiert, unbedingt abfragen. 
Die verbesserte Version der Funktion: 


1: void DrawResourceString (void) 

ZE 

4: StringHandle ourStringHandle; 

5: 

6 ourStringHandle = (StringHandle) 

GetlResource ('STR ', 128); 

3 if (ourStringHandle != NULL) 

8: { 

9: HLock ((Handle) ourStringHandle); 
10: DrawString (*ourStringHandle); 
11: HUnlock ((Handle) ourStringHandle); 
12: } 

133 else DoError (ResError ()); 
14: } 


In der verbesserten Version der Beispielfunktion wird der 
Ergebniswert von Get1Resource auf NULL abgefragt. Ist der Wert 
verschieden von NULL, so war der Resource-Manager beim La- 
den der String-Resource erfolgreich, und wir können mit der 
Ausgabe beginnen. Ist der Wert jedoch gleich NULL, so wird in 
Zeile 13 die (noch zu implementierende) Fehlerbehandlungsroutine 
DoError aufgerufen. Damit DoError dem Benutzer eine Fehler- 





meldung ausgeben kann, die etwas differenzierter ist als "Pro- 
gramm-Error", übergeben wir ihr den Ergebniswert von ResError, 
der Funktion die den Fehlercode der letzten Resource-Manager- 
Funktion zurückgibt. DoError könnte so entweder den Dialog 
"Nicht genügend Speicherplatz vorhanden !" oder "Eine benö- 
tigte Resource konnte nicht geladen werden, das Programm ist 
beschädigt !" ausgeben. 


Dieser Teil des Betriebssystem führt ein stilles und oft unbemerktes 
Schattendasein. Während man sich oft mit dem Memory-Manager 
beschäftigt und manchmal auch den Resource-Manager zum Laden 
bestimmter Resources bemüht, beschäftigen sich nur wenige Teile 
eines Programms mit dem Segment-Loader. Dennoch ist ein 
Verständnis für diesen Manager recht wichtig, da das Wissen 
um die Funktionalität des Segment-Loader für die Erstellung einer 
stabilen, freundlichen Macintosh-Applikation benötigt wird. 

Der Object-Code einer Macintosh-Applikation wird während des 
Compilierens in verschiedene Code-Segmente unterteilt, diedann 
in jeweils einzelnen 'CODE'-Resources abgelegt werden. Diese 
Unterteilung (Segmentierung) eines Programms ermöglicht die 
flexible Verwaltung des ausführbaren Programmcodes. Während 
der Ausführung eines Programms befinden sich nur die Code- 
Segmente im RAM des Macintosh, die gerade benötigt werden. 
Programmteile, die nicht benötigt werden, bleiben auf der Fest- 
platte und verschwenden so keinen Speicherplatz im Speicher- 
bereich der Applikation. Ruft das Programm eine Funktion auf, 
deren Object-Code-Segment sich noch nicht im Speicherbereich 
der Applikation befindet, so wird diese 'CODE'-Resource auto- 
matisch geladen, bevor der Aufruf der Funktion durchgeführt 
wird. Dieses automatische Laden von 'CODE'-Resources wird 
von dem Segment-Loader in enger Zusammenarbeit mit dem 
Resource-Manager erledigt. Glücklicherweise brauchen wir uns 
nicht näher um diese Technik zu kümmern, sondern nur zu ver- 
stehen, daß es so funktioniert. Das Nachladen von 'CODE'-Re- 
sources wird vom Segment-Loader und Resource-Manager au- 
tomatisch durchgeführt, ohne daß das Programm davon Notiz 
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nimmt. Die einzige Auswirkung dieser Technik auf uns, als Pro- 
grammierer, besteht darin, daß wir unseren Programmcode mit 
Hilfe von Compiler-Direktiven sinnvoll segmentieren müssen. 
So ist es beispielsweise sinnvoll, die Segmentierung eines Pro- 
gramms nach logischen, programmablaufspezifischen Kriterien 
vorzunehmen. Üblicherweise steckt man zum Beispiel alle 
Programmteile (Funktionen), die sich mit dem Abspeichern ei- 
ner Datei befassen, in dasselbe Code-Segment, alle Funktionen, 
die sich mit dem Drucken beschäftigen, in ein anderes. Diese 
programmablaufspezifische Segmentierung hat zur Laufzeit des 
Programms den Vorteil, daß beispielsweise die 'CODE'-Resource, 
die die Funktionen zum Drucken eines Dokuments enthält, nur 
dann geladen wird, wenn der Benutzer den Befehl zum Drucken 
gibt. Wenn er während der Laufzeit des Programms überhaupt 
nicht drucken möchte, so wird der entsprechende Programmteil 
bzw. die 'CODE'-Resource nie in den Speicherbereich der App- 
likation geladen, und wir haben mehr Speicherplatz für Pro- 
grammdaten zur Verfügung. 


Dieses Kapitel stellt eine Einführung in die grafischen Möglich- 
keiten des Macintosh dar. Zunächst wird die mathematische 
Grundlage, auf welcher QuickDraw basiert, vorgestellt. An- 
schließend werden die Grafik-Primitives (z.B. Linien und Recht- 
ecke) bzw. die korrespondierenden Datenstrukturen anhand von 
Programmfragmenten erklärt. In den letzten Abschnitten wer- 
den dann kompliziertere Strukturen wie Regions und GrafPorts 
behandelt. 

Die Beschreibung der QuickDraw-Funktionen beschränkt sich 
hier auf die wichtigsten, sozusagen essentiellen Bereiche. Quick- 
Draw bietet viele Utility-Funktionen und abgewandelte Formen 
von hier vorgestellten Routinen, deren Beschreibung jedoch den 
Rahmen des Buches sprengen würde. Für erste Gehversuche in 
der Programmierung des Macintosh werden Sie mit den hier 
vorgestellten Routinen gut zurecht kommen. 


QuickDraw ist ein wesentlicher Bestandteil des Macintosh- 
Gesamtsystems. Auf dem Macintosh wird alles, was Sie auf dem 
Bildschirm sehen, mit Hilfe von QuickDraw gezeichnet; der Mac 
befindet sich sozusagen ständig im Grafikmodus. Es gibt auf dem 
Macintosh keinen Text-Modus, wie dies auf anderen Systemen 
(z.B. MS-DOS) üblich ist. 

QuickDraw ist eine umfangreiche und sehr flexible Grafikbib- 
liothek, die Funktionen zum Zeichen von Grafik-Primitives wie 
Linien, Rechtecken, Ovalen oder Polygonen enthält. Sie enthält 
weiterhin Möglichkeiten zum Zeichnen von Text oder auch Bit- 
Maps (Photos) bzw. Pixel-Maps (farbige Photos). Da alle Pro- 
gramme die Funktionen von QuickDraw benutzen, um Bild- 
schirmausgaben zu erzeugen, gibt es auf dem Macintosh keine 
Probleme mit unterschiedlichen Videokarten, wie dies von an- 


Auf dem Macintosh wird 
alles mit Hilfe von 
QuickDraw gezeichnet. 
Es gibt keinen 
Textmodus. 





deren System her bekannt ist. Macintosh-Programme greifen 
praktisch "doppelt indirekt" auf die Videokarte zu; sie geben 
QuickDraw einen Zeichenbefehl und QuickDraw schreibt dann 
mit Hilfe des Videotreibers der betroffenen Videokarte in den 
Bildschirmspeicher der Karte. 


7.1 Die Mathematische Grundlage von QuickDraw 


QuickDraw basiert auf einem INTEGER-Koordinatensystem, 
dessen Ursprung (0,0) in der linken oberen Ecke des Haupt- 
bildschirms liegt. Der Hauptbildschirm ist der Bildschirm, auf 
dem sich die Menüleiste befindet. Die Konfiguration der Bild- 
schirme, d.h. die Anordnung zueinander bzw. die Festlegung 
des Hauptbildschirmes kann vom Benutzer in dem Kontrollfeld 
"Monitore" (siehe Abb. 7-1) eingestellt werden. Wir können als 
Programmierer also nicht von einer festen Anordnung bzw. 
Priorität der Bildschirme ausgehen. 


AR: g Monitore 
Das 'Monitore’- D1-7.0 


Kontrollfeld. 

Der Benutzer kann die r 
logische Position der = 
Bildschirme an die Bewegen Sie die Monitore und die Menüleiste: 
physikalische anpassen, 
. indem er die Monitor- 
Ikonen verschiebt. 





EEE | (Monitor) 


Die Position des Koordinatensystemursprungs wird in Abb. 7-2 
gezeigt. Der positive Teil der Achsen zeigt immer nach rechts 
bzw. nach unten, der Koordinatensystemursprung liegt in der 
linken oberen Ecke des Hauptbildschirmes. 
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Abb. 7-2 
Die Relation zwischen 
dem Koordinatensystem 
und den Bildschirmen. 
Der Ursprung des 
globalen Koordinatensy- 
stems befindet sich 
immer in der linken 

. oberen Ecke des 
Hauptbildschirms. 





Das in Abb. 7-2 dargestellte Koordinatensystem entspricht dem 
globalen Koordinatensystem. Das globale Koordinatensystem ist 
das Koordinatensystem, in dem die Position und Größe der Fen- 
ster definiert ist. Jedes Fenster hat wiederum sein eigenes Koor- 
dinatensystem, seine eigene Zeichenumgebung. Wird in ein Fenster 
gezeichnet, so gilt das lokale Koordinatensystem dieses Fensters, 
welches seinen Ursprung in der linken oberen Ecke des Fensters 
hat. 


0,0 Global Abb. 7-3 Die Relation 
Zwischen Iokalaı UNE 
globalem Koordinaten- 
system. 

Da jedes Fenster sein 
eigenes Koordinaten- 
system besitzt, braucht 
die Position der Grafik 
nicht neu berechnet zu 
werden, wenn das 
Fenster verschoben 
wird. 


EI “Ein Fenster" auf 100% 2) “Ein Fenster” auf ET «Ein Fenster” auf 100%, 2} —n 
j ° ‚0 Lokal 





87 





grid lines point 


- pixel 


Abb. 7-4 

Die Beziehung zwischen 
Punkt und Koordinate. 
Der Punkt (Pixel) fallt 
immer nach rechts 
unten aus. 





Durch die Konzeption eines globalen bzw. eines lokalen Koordi- 
natensystems ermöglicht QuickDraw das einfache Arbeiten mit 
Fenstern; der Programmierer braucht sich beim Zeichnen einer 
Grafik nicht um die Position des Fensters bezogen auf den Bild- 
schirm zu kümmern, da sich sämtliche Zeichenoperationen auf 
das lokale Koordinatensystem des Fensters beziehen. Abb. 7-3 
zeigt die Beziehung zwischen lokalem und globalem Koordina- 
tensystem. 

Ein Punkt des Koordinatensystems wird durch zwei INTEGER- 
Zahlen (shorts) definiert. Die Struktur Point, die einen Punkt im 
QuickDraw-Koordinatensystem beschreibt, ist daher wie folgt 
deklariert: 


at struct Point { 
23 short v; 
3: short h; 
a: }; 


Ein QuickDraw-Koordinatenpaar ist als "mathematischer" Punkt 
zu verstehen. QuickDraw-Zeichenoperationen beziehen sich immer 
auf dieses "mathematische" Koordinatensystem. Bei linien-ori- 
entierten Grafiken wie Linien und Polygonen muß dann ent- 
schieden werden, in welche Richtung ein Punkt ausfallen soll. 
Bei QuickDraw fällt ein Punkt relativ zum Koordinatenpaar immer 
nach rechts unten aus. Das Verhältnis zwischen Koordinatenpaar 
und betroffenen Bildschirm- bzw. Druckerpunkt wird in Abb. 7- 
4 gezeigt. 


Will man auf dem Macintosh Linien oder Punkte malen, so ge- 
schieht dies mittels den Funktionen MoveTo und LineTo. Beide 
Funktionen verlangen als Eingabeparameter zwei shorts, wel- 
che einen Punkt im QuickDraw-Koordinatensystem beschreiben. 
Das Zeichnen von Linien mit QuickDraw kann man mit einem 
Plotter vergleichen; zunächst gibt man einen Startpunkt im Ko- 
ordinatensystem an (der Plotter-Stift wird an die entsprechende 
Stelle bewegt), anschließend gibt man den Befehl, eine Linie zu 
einem Endpunkt zu zeichnen. Um QuickDraw zum Zeichnen einer 


Linie zu bewegen, wird die Funktion MoveTo mit den Startko- 
ordinaten, und anschließend die Funktion LineTo mit den End- 
koordinaten aufgerufen. MoveTo und LineTo sind wie folgt de- 
klariert: 


pascal void MoveTo (short h, short v); 


pascal void LineTo (short h, short v); 


Ein Beispiel: 
Es soll eine Linie von der Koordinate 100,100 nach 200,200 ge- 
zeichnet werden. 


1: MoveTo (100, 100); 
2: LineTo (200, 200); 


0.0 X(+) 


100,100 


200,200 


y(+) 


LineTo verschiebt genauso wie MoveTo die aktuelle Position 
unseres Plotter-Stiftes, was bewirkt, daß die folgende Sequenz 
ein Dreieck zeichnet: 


: MoveTo (100, 100); 
: LineTo (200, 200); 
: LineTo (0, 200); 

: LineTo (100, 100); 


> wMN HH 


Man kann die Art und Weise, wie QuickDraw Linien zeichnet, 
auf verschiedene Weise beeinflussen; es gibt die Möglichkeit, Breite 
oder Höhe des Zeichenstiftes zu verändern, man kann das Mu- 
ster der "Tinte" verändern oder die Farbe, mit der gezeichnet wird, 


LineTo 


o— een 


Abb. 7-5 
Die Auswirkung des 
LineTo-Befehls. 


Abb. 7-6 

Eine Linie im 
QuickDraw-Koordina- 
tensystem. 





beeinflussen. Für diese Beeinflussungen stehen dem Program- 
mierer unter anderem folgende Funktionen zur Verfügung: 


PenSize pascal void PenSize (short width, short height); 


Abb. 7-7 Pen-Position 
Die Auswirkung des 
PenSize-Befehls. A 
v=3 
Y 





Mit Hilfe von PenSize kann man die Breite bzw. die Höhe der 
"Zeichenfeder" verändern. Die "Feder" des Zeichenstiftes wird 
nach rechts unten vergrößert. So hat die folgende Sequenz die in 
Abb. 7-8 gezeigte Auswirkung: 


1: PenSize (10, 1); 

2: MoveTo (100, 100); 

3: LineTo (100, 200); 

4: LineTo (200, 200); 

5: LineTo (100, 100); 

Abb. 7-8 100,100 
Die Auswirkungen des - 

PenSize-Befehls auf das 
Zeichnen von Linien. 
Hier wurde mit einer 1- 
Punkt hohen und 10- 
Punkt breiten 'Zeichen- 
feder" gearbeitet. 





| 
100,200 200,200 


PenMode PenMode ändert den Zeichen-Modus. Der Zeichen-Modus be- 
stimmt, in welcher Weise die zu zeichnenden Pixel mit den 
übermalten in Beziehung treten. Was sich so kompliziert anhört, 
wird meist lediglich dafür verwendet, um selektierten Text oder 


selektierte Grafik invertiert darzustellen. Dies geschieht, in dem 


7.2 Punkte und Linien 





die Grafik gezeichnet wird, der PenMode auf invertierend gesetzt 

wird, und das umschließende Rechteck der Grafik mit Hilfevon _PaintRect zeichnet ein 
PaintRect gezeichnet wird. Das Resultat entspricht genau dem, Rechteck (wird später 
wie Grafiken oder Texte beispielsweise in Layout-Programmen erläutert). 
selektiert werden. 


pascal void PenMode (short mode); 


Es stehen mehrere Modi zur Verfügung, von denen hier nur die 
wichtigsten beschrieben werden: 


patXor Invertierend 
pator Oder 
patCopy Übermalend (normal) 


Ein Beispiel zu patXOr: 


: MoveTo 
: LineTo 
: LineTo 
LineTo 


U P$wnrnNnH 


(100, 
(200, 
(150, 
(150, 


: PenMode (patXOr); 
: PenSize (10, 


10); 

100); 
200); 
200); 
100); 


Dieses Programmfragment hat die in Abb. 7-9 gezeigte Auswir- 


kung. 


100,100 





150,100 Abb. 7-9 

Die Auswirkungen des 
PenMode-Befehls auf 
LineTo-Befehle. 

Die Bereiche, an denen 
der Stift zweimal 
zeichnet, werden wieder 
weiß. 





150,200 200,200 
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Mit Hilfe von PenPat kann man die "Tinte" des Zeichenstiftes 
verändern. Diese Tinte besteht aus einem Pattern, einem Array, 
PenPat welches aus 8 mal 8 Bits besteht. Jedes Bit in diesem Array entspricht 
einem Bildschirmpunkt beim Zeichnen mit diesem Pattern. Binär 
1 bedeutet einen schwarzen, 0 einen weißen Punkt. 


typedef unsigned char Pattern[8]; 
pascal void PenPat (Pattern *pat); 


PenPat kann man ein vordefiniertes oder selbstdefiniertes Pattern 
übergeben. Dieses Pattern wird dann anstelle der Standard-Ein- 
stellung (black) verwendet. 

Die vordefinierten Patterns wie black, white, gray, ltGray (light 
gray) oder dkGray (dark gray) befinden sich in einem globalen, 
von QuickDraw definierten struct namens "qd" und können di- 
rekt benutzt werden. Um ein selbstdefiniertes Pattern zu erzeu- 
gen, muß man sich eine Variable vom Typ Pattern anlegen und 
die Bits in diesem Pattern selbst setzen. In der Regel reichen die 
von QuickDraw vordefinierten Patterns für die meisten Aufga- 
ben aus. 

Ein kleines Beispiel: 


: PenPat (qd.gray); 
: PenSize (10, 10); 
: MoveTo (100, 100); 
: LineTo (200, 200); 


SwMN Hm 


Dieses Programmfragment zeichnet die Linie mit 50 Prozent grau, 
da die Funktion PenPat aufgerufen wird, und ihr das vordefinierte 
Pattern qd.gray übergeben wird. 


710 100,100 


Die Auswirkung des 
PenPat-Befehls auf das 
Zeichnen einer Linie. 
Bei PenPat (gqd.gray) 
wird nur jeder zweite 

Pixel schwarz gezeich- 200,200 
net. 





Funktionen, die die sogenannten "Pen Attributes" verändern (wie 
PenSize, PenMode und PenPat) haben die Eigenschaft, daß sie 
die Pen-Attribute permanent verändern. Das bedeutet, daß sie 
alle folgenden QuickDraw-Zeichenaktionen beeinflussen. Es 
werden beispielsweise alle Linien, Rechtecke oder Ovale, dienach 
dem Aufruf PenPat (qd.gray) gezeichnet werden mit einem grauen 
Pattern gezeichnet. Diese Eigenschaft ist recht nützlich, kann jedoch 
auch Verwirrung stiften. Normalerweise benutzt man daher bevor 
Zeichenroutinen aufgerufen werden, die QuickDraw-Funktion 
PenNormal, welche die Pen-Attribute auf ihre Standard-Werte 
zurücksetzt. 


: PenNormal (); 
PenPat (qd.gray); 
: PenSize (10, 10); 
: MoveTo (100, 100); 
: LineTo (200, 200); 


PN H 


Auf diese Weise können wir sicher sein, daß eventuell vorange- 
gangene Änderungen der Pen-Attribute unsere Zeichnung nicht 


N 


beeinflussen. 


Da das Zeichnen von Linien (wie beschrieben) mit einem Plotter 
verglichen werden kann, bietet QuickDraw auch die Möglichkeit, 
den Plotter-Stift zu heben bzw. zu senken. Wird der Plotter-Stift 
angehoben, so hat keine QuickDraw-Zeichenfunktion Auswir- 
kungen auf den Bildschirm. QuickDraw stellt für dieses Anhe- 
ben bzw. Absenken des Plotter-Stiftes die Funktionen HidePen 
bzw. ShowPen zur Verfügung. Durch die Verwendung dieser 
Funktionen kann man die grafische Ausgabe von Unterroutinen 
unterdrücken. Die beiden Funktionen sind wie folgt deklariert: 


pascal void HidePen (void); 
Wenn während des Zeichnens einer Grafik der Zeichenstift 
hochgehoben werden soll, so kann man dies mit Hilfe der Funktion 


HidePen tun. 


pascal void ShowPen (void); 


PenlVormal 


HidePen / ShowPen 
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QuickDraw 
ER Ein Aufruf der Funktion ShowPen hebt die Wirkung eines kor- 


respondierenden HidePen-Aufrufs wieder auf. 

Aufrufe von HidePen bzw. ShowPen müssen ausgeglichen sein. 
Wird zweimal hintereinander HidePen aufgerufen, und nur ein- 
mal ShowPen, so wird nicht gezeichnet ! 


7.3 Rechtecke und Övale 


Zu den Grafik-Primitives gehören auch die Rechtecke bzw. die 
Ovale. Diese Grafikelemente sind recht einfach und flexibel zu 
benutzen und basieren auf einer Datenstruktur namens Rect. Ein 
Rect beschreibt ein Rechteck und ist wie folgt deklariert: 


FrameRect 
1: struct Rect { 
8 | 2 short top; 
bt] 3 short left; 
4: short bottom; 
> | I] | 5% short right; 
Pe 6: 
1 7: 
8: typedef struct Rect Rect; 


Die Felder top, left, bottom und right beschreiben das Rechteck 
PaintRect im QuickDraw-INTEGER-Koordinatensystem. Willmannun ein 
Rechteck zeichnen, kann man die Funktion FrameRect oder 
PaintRect benutzen. Diese Funktionen erwarten jeweils einen 
Parameter vom Typ Rect. 


| H pascal void FrameRect (const Rect *r); 


pascal void PaintRect (const Rect *r); 


Abb. 7-11 Im Gegensatz zu den linien-orientierten Strukturen (wie LineTo) 
FrameRectund fallen die mit FrameRect oder PaintRect gemalten Rechtecke nicht 
PaintRect. nach rechts unten aus. Dies kommt daher, daß es bei diesen 
"mathematisch definierten" Objekten im Gegensatz zu linien- 

orientierten Strukturen eine eindeutig beschreibbare Fläche gibt. 
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Die folgende Funktion zeichnet die Umrandung (den Frame) ei- 
nes Rechtecks: 


1: void DrawFigure (void) 
2: { 

3 Rect myRect; 

4: 

5% myRect.top = 100; 
6: myRect .left = 100; 
7 myRect..bottom = 200; 
8 myRect.right = 200; 
9% FrameRect (&myRect); 
10: } 


Vereinfachen läßt sich die (etwas aufwendige) einzelneZuweisung sSetRect 
der Koordinaten mit der Hilfsfunktion SetRect, die QuickDraw 

zu diesem Zweck zur Verfügung stellt. SetRect übernimmt die 
Zuweisung der einzelnen Felder eines Rects, die wir im voran- 
gegangenen Beispiel noch sozusagen "zu Fuß" durchführen 

mußten. 


pascal void SetRect ( Rect xD, 
short left, 
short top, 
short right, 
short bottom); 


Dementsprechend verkürzt sich unsere kleine Funktion wie folgt: 


void DrawFigure (void) 


{ 
Rect myRect; 


a 
2 
3 
4: 
5 SetRect (&myRect, 100, 100, 200, 200); 

6 FrameRect (&myRect); 

7:2} 

Ovale werden wie Rechtecke behandelt; das angegebene Recht- PaintOval/FrameOval 
eck beschreibt dann das umschließende Rechteck des Ovals. Zum 

Zeichnen von Ovalen stehen die Funktionen FrameOval und 

PaintOval zur Verfügung. 


Kapitel 7 


(eine 18/117 





96 


Abb. 7-12 

FrameRect und 
PaintOval. 

PaintOval zeichnet das 
Oval, welches in das 
Rechteck paßt. 





pascal void FrameOval (const Rect *r); 


pascal void PaintOval (const Rect *r); 


Wenn wir unsere Funktion wie im nächsten Beispiel gezeigt er- 
weitern, so resultiert dies in der in Abb. 7-12 dargestellten Gra- 
fik. 


: void DrawFigure (void) 


{ 
Rect myRect; 


SetRect (&myRect, 100, 100, 200, 200); 
FrameRect (&myRect); 
PaintOval (&myRect); 


oo PbwnrNnH 
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7.4 Polygone 


Polygone sind eine etwas kompliziertere, jedoch sehr leistungs- 
fähige Struktur von QuickDraw. Die Definition eines Polygons 
kann man mit dem Bespielen eines Tonbands vergleichen. Zu- 
nächst teilt man QuickDraw mit, daß man die Aufzeichnung eines 
Polygons beginnen möchte. Dies würde in etwa dem Drücken 
des Aufnahmeknopfes des fiktiven Tonbands entsprechen. An- 
schließend definiert man die Figur des Polygons durch den 
wiederholten Aufruf der LineTo-Funktion (auf das Tonband 





sprechen) und schaltet zum Schluß die Aufzeichnung ab. Nun 
haben wir ein auf" Tonband" aufgezeichnetes Polygon und können 
es jederzeit mit einem Aufruf zeichnen. 

Natürlich hinkt der eben benutzte Vergleich mit einem Tonband 
etwas. Die Daten des Polygons (die Koordinaten der Eckpunkte) 
werden selbstverständlich nicht auf einem Tonband aufgezeich- 
net, sondern mit einem Handle verwaltet. QuickDraw besitzt auch 
keine Knöpfe zum Aufzeichnen von Koordinaten, sondern bie- 
tet stattdessen drei Funktionen an: 


PolyHandle OpenPoly (void); 


OpenPoly alloziiert einen Handle für die Daten unseres Poly- 
gons und gibt diesen PolyHandle als Ergebniswert zurück. 
Gleichzeitig startet OpenPoly die Aufzeichnung aller nachfol- 
genden MoveTo- und LineTo-Befehle. Die Koordinaten der Befehle 
werden von QuickDraw in dem von OpenPoly angelegten Poly- 
Handle abgelegt. Während der Aufzeichnung werden keine Li- 
nien auf dem Bildschirm gezeichnet, die LineTo-Befehle dienen 
lediglich der Definition des Polygons. 

Ein PolyHandle verwaltet eine Struktur vom Typ Polygon: 


1 struct Polygon { 

2 short polySize; 

3 Rect polyBBox; 

4: Point polyPoints[1]; 

Ss: hr 

6: 

7: typedef struct Polygon *PolyPtr, 


**PolyHandle; 


Das Feld polySize gibt die Größe des Polygons in Bytes an. Da 
polySize ein short ist, beschränkt QuickDraw die Anzahl der 
Eckkoordinaten eines Polygons auf 8000 Koordinatenpaare. Das 
Rect polyBBox entspricht dem umschliessenden Rechteck des 
Polygons (aller Eckkoordinaten) und wird während der Auf- 
zeichnung des Polygons automatisch berechnet. Ein Polygon-struct 
ist ein sogenannter "Open Array", d.h. daß beginnend mit dem 
Feld polyPoints[0] die Eckkoordinaten des Polygons in dieser 
Struktur enthalten sind. Enthält ein Polygon beispielsweise 20 





OpenPoly 





Abb. 7-13 

Ein Polygon und die 
Datenstrukturen im 
Speicherbereich. 

Das Programm 
verwaltet ein Polygon 
mit Hilfe einer Variablen 
vom Typ PolyHandie. 
Dieser zeigt auf eine 
Struktur vom Typ 
Polygon, welche die 
Polygon-Daten enthält. 


CGlosePoly 


Eckkoordinaten, so können wir den Array polyPoints bis 
polyPoints[19] adressieren, um auf die Eckkoordinaten des Po- 
lygons zuzugreifen. Der Block, in dem sich der Open-Array be- 
findet, wird während der Aufzeichnung des Polygons ständig 
vergrößert. Daher belegt ein Polygon mit 20 Eckkoordinaten we- 
niger Speicherplatz im Speicherbereich der Applikation als eines 
mit 300. Abb. 7-13 zeigt, wie ein Polygon verwaltet wird bzw. 
wie seine Struktur im Speicherbereich der Applikation liegt. 


0,0 


0,100 100,100 


Variable im Heap 
Programm 


polySize 
polyBBox 
polyPoints[0] 
polyPoints[1] 
polyPoints[2] 
polyPoints[3] 





Soll die Konstruktion eines Polygons beendet werden, so wird 
die Funktion ClosePoly aufgerufen. ClosePoly beendet die au- 
tomatische Aufzeichnung aller MoveTo- und LineTo-Befehle in 
das durch OpenPoly angelegte Polygon. 


pascal void ClosePoly (void); 


Nachdem die Definition des Polygon abgeschlossen wurde, kann 
das Polygon für Zeichenoperationen verwendet werden. 


Die Funktionen FramePoly bzw. PaintPoly sind für das Zeich- 
nen eines bereits definierten Polygons zu verwenden (vergleich- 
bar mit FrameRect und PaintRect). 


pascal void FramePoly (PolyHandle poly); 


pascal void PaintPoly (PolyHandle poly); 


Beim Zeichnen der Umrandung eines Polygons mit Hilfe von 
FramePoly ist darauf zu achten, daß die Umrandung des Polygons 
nach rechts unten ausfällt. Dieses Verhalten ist darauf zurück- 
zuführen, daß ein Polygon mit Hilfe von LineTo-Befehlen defi- 
niert ist, also eine linien-orientierte Struktur ist. 


Es folgt ein Beispiel für das Definieren und Zeichnen eines Poly- 
gons: 


: void DrawMyPoly (void) 
{ 
PolyHandle myPoly; 


myPoly = OpenPoly (); 
MoveTo (200, 50); 
LineTo (300, 300); 
LineTo (50, 150); 
LineTo (350, 150); 
LineTo (100, 300); 
LineTo (200, 50); 
ClosePoly (); 
PaintPoly (myPoly); 
KillPoly (myPoly); 
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Abb. 7-15 zeigt das Resultat dieser Beispielfunktion. Das Poly- 
gon hat die Form eines Sternes. Interessant ist die Reaktion von 
PaintPoly auf die komplizierte Form dieses Polygons. 


7.4 Polygone 
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Abb. 7-14 

FramePoly und 
PaintPoly. 

Die Linien, welche durch 
FramePoly gezeichnet 
werden, fallen nach 
rechts unten aus, da 
Polygone zu den 
linienorientierten 
Strukturen gehören. 





7-15 

Ein mit Hilfe eines 
Polygons gezeichneter 
Stern. 
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In der Funktion DrawMyPoly wird die lokale Variable myPoly 
(vom Typ PolyHandle) deklariert, um zur Verwaltung der Polygon- 
Daten (der Eckkoordinaten) verwendet zu werden. In Zeile5 wird 
die Funktion OpenPoly benutzt, um die Aufzeichnung der 
nachfolgenden MoveTo/LineTo-Befehle zu starten. OpenPoly 
alloziiert auch einen Handle vom Typ PolyHandle, um die Eck- 
koordinaten des Polygons darin zu speichern. In Zeile 6 wird ein 
initialer MoveTo-Befehl ausgeführt, um dem Polygon einen 
Ausgangspunkt zu geben. Die nachfolgenden LineTo-Befehle 
beschreiben die Eckpunkte bzw. die Umrandung des Polygons. 
Diese Zeichenbefehle haben, während ein Polygon zur Defini- 
tion geöffnet ist, keine Auswirkungen auf den Bildschirm; sie 
werden nur zur Definition der Eckkoordinaten benutzt, Auswir- 
kungen auf den Bildschirm werden von QuickDraw unterdrückt. 
In Zeile 12 wird die Definition des Polygons mit einem ClosePoly- 
Befehl abgeschlossen. Der ClosePoly-Befehl teilt QuickDraw mit, 
daß nachfolgende LineTo-Befehle nicht mehr zur Definition des 
Polygons verwendet werden, sondern daß sie jetzt wieder auf 
dem Bildschirm angezeigt werden sollen. 

In Zeile 13 wird das gerade definierte Polygon mittels eines 
PaintPoly-Befehls auf den Bildschirm gezeichnet. PaintPoly füllt, 
wie PaintRect, das Innere der Figur in der aktuellen Farbe und 
dem aktuellen Pattern. 

Zeile 14 schließt den gesamten Prozeß ab, indem der von OpenPoly 
angelegte PolyHandle durch den Aufruf von KillPoly freigege- 


ben wird. KillPoly hat denselben Effekt wie DisposeHandle; der 
Block im Speicherbereich wird zum Überschreiben freigegeben. 


75 Text 


QuickDraw bietet selbstverständlich auch die Möglichkeit, Text 
auszugeben. Zu diesem Zweck werden mehrere Funktionen 
angeboten, von denen hier zwei vorgestellt werden. Die Funk- 
tion DrawString stellt eine recht einfache Möglichkeit dar, Text 
auf dem Bildschirm darzustellen. Sie verlangt als Eingabeparameter 
die Adresse eines Pascal-Strings (Str255). 


pascal void DrawString (Str255 *s); 


DrawString zeichnet den im Pascal-String enthaltenen Text an 
der aktuellen Pen-Position. Dies bedeutet, daß wir zunächst mit 
einem MoveTo-Befehl dafür sorgen müssen, daß die Pen-Position 
auf den Punkt gesetzt wird, an dem unser Text auf den Bildschirm 
gezeichnet werden soll. Das nachfolgende Beispiel bewirkt die 
in Abb. 7-16 gezeigte Bildschirmausgabe. 


1: void DrawMyText (void) 

2: { 

3% MoveTo (100, 100); 

4 DrawString ("\pgezeichneter Text"); 
5 


2} 


‚gezeichneter Text 


100,100 


Bei der Ausgabe des Strings ist darauf zu achten, daß die Pen- 
Position auf der Basislinie der Schrift steht. Das kleine "g" ragt 
nach unten hinaus. 

DrawString setzt eine definierte Pen-Position voraus und ver- 
schiebt diese während des Zeichnens. Nach dem Zeichnen eines 
Strings befindet sich die Pen-Position hinter dem letzten Buch- 
staben des gezeichneten Textes. Ein erneuter DrawString-Be- 
fehl hängt den neuen Text daher hinter den ersten Text an. Die- 


DrawString 


Abb. 7-16 
Textausgabe mit Hilfe 
von DrawString. 
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Abb. 7-17 

Zwei Zeilen Text, die mit 
Hilfe von DrawString 
gezeichnet wurden. 


DrawText 





ses Verhalten hat seine Vor- und Nachteile; möchte man bei- 
spielsweise eine Folge von Text auf den Bildschirm zeichnen, so 
kann man dies ganz einfach durch wiederholtes Aufrufen von 
DrawString tun. Da DrawString jedoch keine Möglichkeit eines 
Line-Feeds bietet, muß die Pen-Position "zu Fuß" neu gesetzt 
werden, wenn eine zweite Zeile ausgegeben werden soll. 


l: void DrawMyText (void) 
2: { 
35 MoveTo (100, 100); 

4: DrawString ("\pgezeichneter Text"); 
94 DrawString ("\p noch mehr Text"); 

6 MoveTo (100, 120); 
7 DrawString ("\pzweite Zeile"); 
8 


2 


gezeichneter Text noch mehr Text 
” Zweite Zeile 


100,120 


100,1 


Der zweite Aufruf von DrawString hängt den zu zeichnenden 
Text an den zuletzt gezeichneten an, da der erste Aufruf die Pen- 
Position hinter den zuletzt gezeichneten Buchstaben verschiebt. 
In Zeile 5 wird die Pen-Position neu gesetzt, um ein Line-Feed 
zu emulieren. 


Viele Textverarbeitungsprogramme verwenden eine andere 
Funktion zum Ausgeben von Text. Die Funktion DrawText bie- 
tet die Möglichkeit, Text, der beispielsweise mit einem Handle 
verwaltet wird, sehr flexibel auf den Bildschirm zu zeichnen. 
DrawText verlangt als Eingabeparameter die Adresse des aus- 
zugebenden Textes, und bietet mit den Parametern firstByte und 
byteCount die Möglichkeit, einen bestimmten Bereich des Tex- 
tes auszugeben. 


pascal void DrawText ( const void *textBuf, 
short firstByte, 
short byteCount); 





Der Input-Parameter firstByte spezifiziert den ersten Buchsta- 
ben, der gezeichnet werden soll (ausgehend von dem Buchsta- 
ben, auf den textBuf zeigt). byteCount gibt die Anzahl der Aus- 
zugebenden Buchstaben an. So zeichnet das nachfolgende Beispiel 
nur das Wort "Text" aus dem übergebenen String. 


: void DrawMyText (void) 
{ 
MoveTo (100, 100); 
DrawText ("gezeichneter Text", 13, 4); 


$wNrNnH 


Nun wäre es recht langweilig, auf einem Grafiksystem wie dem 
Apple Macintosh Text immer in derselben Größe bzw. derselben 
Schriftart zu zeichnen. Selbstverständlich bietet QuickDraw auch 
Manipulationsmöglichkeiten für die Schriftgröße, die Schriftart 
oder auch denSchriftschnitt an. Diese Manipulationsmöglichkeiten 
funktionieren vergleichbar mit den Änderungen der Pen-Attribute 
wie PenSize oder PenPattern. 


Die Funktion TextFont erlaubt die Umstellung der Schriftart auf 
alle im Betriebssystem installierten Schriften. 


pascal void TextFont (short font); 


Ein Macintosh-Programm kann nur die (fest installierten) 
Schriftarten Geneva, Monaco und Times voraussetzen. Alle an- 
deren Schriftarten (wie z.B. Helvetica oder Palatino) können vom 
Benutzer installiert oder auch entfernt werden. Die fest instal- 
lierten Schriften werden daher auch von den meisten Program- 
men zur Darstellung von Text in Dialogen oder für andere 
Programmausgaben verwendet. Textverarbeitungsprogramme 
erlauben es dem Benutzer selbstverständlich, den eingegebenen 
Text in den verschiedensten Schriftarten zu formatierten. Pro- 
grammeldungen und andere, nicht vom Benutzer eingegebene 
Texte sollten jedoch immer in Monaco, Geneva oder Times gehalten 
werden, um die Einheitlichkeit des User-Interfaces auf dem 
Macintosh zu bewahren. Kümmern wir uns daher erst einmal 
um die Ausgabe von Text in den Standard-Schriftarten. QuickDraw 
identifiziert Schriften über eine INTEGER-Zahl, die sogenannte 


TextFont 
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Abb. 7-18 

Die Unterteilung des 
Style-Bytes. 

Jedes Bit entspricht 
einem Schriftstil. Ist das 
Bit gesetzt, so wird der 
entsprechende Schrift- 
stil angewendet. 


"Font ID". Für die Standard-Schriften (wie Geneva oder Mona- 
co) bietet QuickDraw vordefinierte Konstanten an. Diese Kon- 
stanten entsprechen einer bestimmten Font-ID und können als 
Parameter für TextFont verwendet werden. Für die Standard- 
Schriftarten gibt es folgenden Konstanten: 


#define geneva 3 
#define monaco 4 
#define times 20 


Um den Schriftstil des zu zeichnenden Textes zu ändern, kann 
die Funktion TextFace verwendet werden. 


pascal void TextFace (short face); 


Mit TextFace kann man den Schriftstil beispielsweise auf italic 
oder bold oder bold+italic ändern. Zu diesem Zweck verlangt 
TextFace einen short als Parameter, welcher ein Bit-Feld darstellt, 
in dem jeweils ein Bit mit einem bestimmten Schriftstil assoziiert 
ist. Jedes Bit in dem Bit-Feld entspricht einem bestimmten Stil. 
Ist das Bit gesetzt, so werden die nächsten DrawString- oder 
DrawText-Befehle den Text in dem entsprechenden Schriftstil 
ausgeben. Da face ein Bit-Feld ist, sind beliebige Kombinationen 
der Schriftstile möglich: Beispielsweise bold+italictunderline+ 
outline (eine schreckliche Kombination). 


extend 
shadow 
underline 
bold 


Style = 1 Byte 





italic 
outline 
condense 


QuickDraw bietet vordefinierte Konstanten für die Manipulati- 
on des Schriftstils an, die den Schriftstil-Namen entsprechen, und 
das entsprechende Bit gesetzt haben. Diese Konstanten sind: 


7.5 Text 


#define normal 0 
#define bold 1 
#define italic 2 
#define underline 4 
#define outline 8 
#define shadow 0x10 
#define condense 0x20 
#define extend 0x40 


Übrigens: Hier wird ein recht nützlicher Trick zum Setzen einer Bit- 
Feld-Konstanten verwendet : 0x10 = hexadezimal $10 = binär 10000. 
In C kann die Konstruktion 0x verwendet werden, um einer Variablen 
oder Konstanten einen hexadezimalen Wert zuzuweisen. 


Mit der Funktion TextSize kann man (wie der Name bereits ver- TextSize 
muten läßt) die Schriftgröße verändern. 


pascal void TextSize (short size); 


Der Parameter size gibt bei einem Aufruf von TextSize die Grö- 
ße der Schrift in Point (1/72 inch = 1 Bildschirmpunkt) an. 


Das folgende Programmfragment demonstriert die verschiede- 
nen Schrift-Manipulationsmöglichkeiten: 


1: void DrawMyText (Str255 *s, Point location) 
2: % 

3: TextFont (geneva); 

4: TextFace (italic); 

5. TextSize (24); 

6: MoveTo (location.h, location.v); 

T: DrawString (s); 

8: } 

9: 
10: Point textPosition; 
1: 
12: void main (void) 

13: { 

14: textPosition.h = textPosition.v = 100; 
19% DrawMyText ("\pGarfield", textPosition); 
16: } 








Abb 7-19 
Die Kombination von 
Schriftattributen. 


StringWidth 


TextWidth 





Frarfield 1 24 Punkte 
100,100 


Da viele Schriftarten verschiedene Buchstabenbreiten besitzen 
(nicht-proportionale Schriften), ist es oft wichtig zu wissen, wie 
breit ein String beim Zeichnen wird. Dies ist beispielsweise dann 
interessant, wenn man Text zentriert ausgeben möchte. Zu die- 
sem Zweck bietet QuickDraw zwei Funktionen an, die in Kom- 
bination mit DrawString bzw. DrawText benutzt werden kön- 
nen. 


pascal short StringWidth (Str255 *s); 


StringWidth gibt die Breite des Strings in Point (1/72 inch) als 
Ergebniswert zurück. Bei der Berechnung werden auch die ak- 
tuellen Text-Attribute (Schriftart, Schriftschnitt und Schriftgröße) 
berücksichtigt, die ja die Breite des Textes beeinflussen. 


pascal short TextWidth ( const void *textBuf, 
short firstByte, 
short byteCount); 


TextWidth funktioniert wie StringWidth, bietet jedoch dieselbe 
Flexibilität bei der Adressierung des zu messenden Buchstaben, 
wie DrawText dies für die Ausgabe von Text tut. 

Hier ein Beispiel zur Ausgabe von zentriertem Text: 


1: void DrawCenteredText ( Str255 *%s, 
Point location) 


2 

3% short centeredHoriz; 

4 

5 centeredHoriz = location.h - 
StringWidth (s) / 2; 


MoveTo (centeredHoriz , location.v); 
DrawString (s); 


: Point textPosition; 


7.6 Regions 





12: void main (void) 


13: { 
14: textPosition.h = textPosition.v = 100; 
15% DrawMyText ("\pGarfield,", textPosition); 
16: textPosition.v += 20; 
17: DrawCenteredText ("\pder dicke Kater", 
textPosition); 
18: } 
100 Abb. 7-20 
Die Positionierung für 


zentrierten Text kann 
100 mit Hilfe von 


6 StringWidth berechnet 
120 werden. 

7.6 Regions 

Eine der wichtigsten und flexibelsten Möglichkeiten von Quick- 

Draw sind Regions. Eine Region ist eine Struktur, die einen Bereich 

im QuickDraw-Koordinatensystem beschreibt. Es gibt keine Be- 

schränkung für die Form einer Region. Eine Region kann unre- 

gelmäßige Formen beschreiben, wie dies in Abb. 7-21 gezeigt wird, 

sie kann von einander unabhängige Flächen beschreiben oder 

auch Löcher in der Fläche haben. 
Abb. 7-21 
Zwei Regions. 
Die weißen Bereiche 
beschreiben die Fläche 
der beiden Regions. 
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Abb. 7-21 

Sämtliche QuickDraw- 
Zeichenoperationen 
werden auf den Bereich 
beschränkt, den die 
Clipping-Region 
beschreibt; sie wirkt wie 
ein Passepartout. 


Die wichtigste Anwendung von Regions liegt im Beschneiden 
des Zeichenbereiches, dem sogenannten "Clipping". QuickDraw 
verwaltet eine Region, die sogenannte "Clipping Region", diezum 
Beschneiden des Zeichenbereichs verwendet werden kann. Die 
Clipping-Region wirkt wie ein Passepartout. Nur die Bereiche 
einer Grafik, die innerhalb dieser Region liegen werden sichtbar. 
Abbildung 7-22 illustriert das Prinzip des Clippings, bzw. die 
Wirkung der Clipping-Region (schwarz) als Passepartout. Hier 
beschneidet die Clipping-Region das Zeichnen eines Photos. 





Alle QuickDraw-Befehle zeichnen nur soweit, wie sich die be- 
troffenen Bildschirmpunkte innerhalb der Clipping-Region be- 
finden. Initial beschreibt die Clipping-Region eine (in QuickDraw- 
Koordinaten) unendliche Fläche, d.h. daß die gesamte Fläche des 
Koordinatensystems zum Zeichnen zur Verfügung steht. Mit Hilfe 
bestimmter QuickDraw-Befehle kann man die initiale Clipping- 
Region durch eine selbstdefinierte Region ersetzen und damit 
sämtliche Zeichen-Effekte auf den Bereich, den diese Region be- 





schreibt, beschränken. Regions werden in vielen Macintosh-Pro- 
grammen verwendet, um den Zeichenbereich auf bestimmte 
Formen zu beschränken. Eine sinnvolle, und weit verbreitete 
Anwendung für eine solche Beschränkung des Zeichenbereiches 
liegt beispielsweise darin, eine Grafik oder Text in einem kleinen 
Fensterausschnitt darzustellen und dem Benutzer mit Hilfe von 
Scrollbars (Verschieben des Darstellungsbereiches) die Möglich- 
keit zu geben, die gesamte Grafik zu sehen. In diesem Fall wird 
die Clipping-Region auf den Darstellungsbereich gesetzt und die 
gesamte Grafik gezeichnet. Auf diese Weise erreicht man sehr 
einfach und effizient, daß die Grafik nicht über den Darstel- 
lungsbereich hinauszeichnet. 

Regions sind Handle-basierte Strukturen, ihre Definition funk- 
tioniert ähnlich wie die von Polygonen. Zunächst wird Quick- 
Draw der Befehl gegeben, die Aufzeichnung von Grafikbefehlen 
in eine Region-Struktur zu starten. Dann werden QuickDraw- 
Befehle wie PaintRect oder PaintOval dazu verwendet, die Form 
der Region zu beschreiben. Abgeschlossen wird die Definition 
einer Region mit einem Befehl, der QuickDraw mitteilt, daß die 
Aufzeichnung der Grafikbefehle in die Region gestoppt werden 
soll. Während eine Region definiert wird, haben QuickDraw- 
Befehle keine Auswirkungen auf den Bildschirm; die Befehle 
werden nur dazu verwendet, die Bereiche, die sie beschreiben, 
in die Region zu akkumulieren. 

Die Datenstruktur, auf die ein RgnHandle zeigt, beinhaltet in 
dem Feld rgnSize die Anzahl der Bytes, die die Region im Spei- 
cher belegt, bzw. das umschließende Rechteck der Region in dem 
Feld rgnBBox (Region-Bounding-Box). Die Datenstruktur, dieden 
Bereich der Region beschreibt, folgt hinter dem Feld rgnBBox, 
obwohl kein Array oder sonstige Felder erkennbar sind, die die 
Form definieren. Apple gibt das Format dieser Datenstruktur 
nicht bekannt, da sie eine Schlüsseltechnologie zur Implemen- 
tierung einer hochwertigen grafischen Benutzeroberfläche dar- 
stellt. (Regions werden beispielsweise für das Window-Manage- 
ment dringend benötigt) 





Das Aufzeichnen einer 
Region ist vergleichbar 
mit der Definition eines 
Polygons 
(Tonbandfunktionalität). 





NewRgn 


OpenRgn 


GloseRgn 


DisposeRgn 


SetClip 





1: struct Region { 

2 short rgnSize; 

3% Rect rgnBBox; 

4: }; 

3% 

6: typedef struct Region *RgnPtr, **RgnHandle; 


Für die Definition und Verwendung von Regions stehen dem 
Macintosh-Programmierer unter anderem folgende Funktionen 
zur Verfügung: 


pascal RgnHandle NewRgn (void); 
NewRgn alloziiert eine leere Region. 
pascal void OpenRgn (void); 


OpenRgn startet die Aufzeichnung von QuickDraw-Befehlen in 
eine von QuickDraw verwaltete Region. 


pascal void CloseRgn (RgnHandle dstRan); 


CloseRgn stoppt die Aufzeichnung von QuickDraw-Befehlen und 
kopiert die generierte Region in dstRgn. Die Region dstRgn muß 
vorher mit NewRgpn alloziiert werden. Die so definierte Region 
kann jetzt zum Clipping (Beschneiden des Zeichenbereiches) oder 
auch zum Zeichnen verwendet werden. 


pascal void DisposeRgn (RgnHandle rgn); 


Die Funktion DisposeRgn gibt die Region frei, welche durch dem 
Parameter rgn spezifiziert wird. Sie gibt den Block, in dem sich 
die Region befindet, für den Memory-Manager zum Überschrei- 
ben frei. 


pascal void SetClip (RgnHandle ran); 


SetClip beschränkt den aktuellen Zeichenbereich (die Clipping- 
Region) auf die Region, die SetClip übergeben wird. Alle Quick- 
Draw-Befehle zeichnen nach diesem Aufruf nur soweit, wie sich 
die betroffenen Bildschirmpunkte innerhalb der neuen Clipping- 


Region befinden. SetClip kopiert die übergebene Region in die 
Clipping-Region. Dieses Kopieren bedeutet, daß ein Duplikat des 
übergebenen Handles angelegt wird, um den Zeichenbereich zu 
beschränken. Wir sind nach dem Aufruf von SetClip also weiter- 
hin für die Verwaltung des Region-Handles verantwortlich. 


Die Funktion ClipRect kann dazu verwendet werden, den Zei- 
chenbereich auf ein Rechteck zu beschränken. Sie stellt damit 
(im Vergleich zu SetClip) eine einfachere Möglichkeit dar, die 
Zeichenumgebung einzuschränken, da keine Region erzeugt 
werden muß. 


pascal void ClipRect (const Rect *r); 


ClipRect setzt die Clipping-Region der Zeichenumgebung auf 
den Bereich, der durch das Rechteck, auf welches der Parameter 
r zeigt, beschrieben wird. 


pascal void GetClip (RgnHandle rgn); 


GetClip kopiert die aktuelle Clipping-Region in die Region, die 
als Parameter übergeben wird. GetClip setzt dabei voraus, daß 
die übergebene Region bereits mit NewRgn angelegt wurde. Diese 
Funktion wird in der Regel dazu verwendet, die aktuelle Clipping- 
Region zu retten, den Zeichenbereich mit einem SetClip-Aufruf 
einzuschränken, eine Grafik zu zeichnen und anschließend die 
Clipping-Region wieder auf die gerettete Region zurückzuset- 
zen. 


Das folgende Beispiel demonstriert die Verwendung einer 
Clipping-Region, um das Zeichnen von Text bzw. eines Recht- 
ecks auf einen kreisförmigen Bereich zu beschränken: 


1: void DrawClippedGraphics (void) 
2 
3: RgnHandle oldClip, newClip; 
4: Rect ovalRect, clippedRect; 
5 
6 
7 
8 


OpenRan (); 
SetRect (&ovalRect, 100, 100, 200, 200); 
PaintOval (&ovalRect); 


ClipRect 


GetClip 
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Abb. 7-23 

Geclippter Text. 
DrawString und 
PaintRect zeichnen nur 
an den Bereichen, 
welche sich innerhalb 
der Glipping-Region 
befinden. Der angedeu- 
tete Kreis beschreibt 
diese Clipping-Region. 





9: newclip = NewRgn (); 
10: CloseRgn (newClip); 

Lie oldClip = NewRgn (); 

12: GetClip (oldClip); 

13: SetClip (newClip); 

14: MoveTo (50, 150); 
15; DrawString ("\pDieser Text wird geclipped 

gezeichnet"); 

16: SetRect (&clippedRect, 150, 150, 300, 300); 
Ir PaintRect (&clippedRect); 

18: SetClip (oldClip); 

1:98 DisposeRgn (oldClip); 
20: DisposeRgn (newClip); 
21: } 

100,100 
- 





50,150 1 
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In Zeile 6 wird die Definition einer Region begonnen, die im 
weiteren Verlauf zum Beschränken des Zeichenbereiches ver- 
wendet werden soll. Alle QuickDraw-Befehle die nach OpenRgn 
folgen, definieren die Region. Da wir unsere Grafik kreisförmig 
beschränken wollen, wird in Zeile 8 der QuickDraw-Befehl 
PaintOval verwendet, um der Region eine Kreisform zu geben. 
Um mit der Region arbeiten zu können, müssen wir QuickDraw 
dazu überreden, uns eine Kopie der in Definition befindlichen 
Region zu geben. Dies geschieht in dem Moment, wenn wir die 
Definition der Region mittels CloseRgn in Zeile 10 abschließen. 
Da CloseRgn die von QuickDraw verwaltete Region in die 
übergebene Region kopiert, müssen wir in Zeile 9 zunächst mit 





Hilfe von NewRgn dafür sorgen, daß wir eine leere Region allo- 
ziiert haben, in die CloseRgn hineinkopieren kann. Nach dem 
Aufruf von CloseRgn haben wir eine kreisförmige Region, die 
mit der Variablen newClip verwaltet wird. 

Bevor der Zeichenbereich eingeschränkt wird (die Clipping-Region 
gesetzt wird), sollten wir uns eine Kopie der aktuellen Clipping- 
Region anlegen, da eine Änderung der Clipping-Region perma- 
nent ist, d.h. daß auch andere Teile des Programms von der 
kreisförmigen Clipping-Region betroffen wären. Daher veran- 
lassen wir QuickDraw in Zeile 12 mit dem Aufruf von GetClip 
dazu, die aktuelle Clipping-Region in die lokale Variable oldClip 
zu kopieren. GetClip geht genauso wie CloseRgn davon aus, daß 
die übergebene Region bereits alloziiert ist, also wird dies in Zeile 
11 mit dem Aufruf von NewRgn getan. 

In Zeile 13 wird nun schließlich der Zeichenbereich auf unsere 
kreisförmige Region beschränkt. Der Befehl SetClip setzt die 
Clipping-Region auf die kreisförmige Region. Alle nachfolgen- 
den QuickDraw-Befehle zeichnen nun nur soweit, bis sie an die 
Grenzen des Kreises stoßen. Wir brauchen uns durch diese Technik 
netterweise überhaupt nicht mehr darum zu kümmern, ob Teile 
unserer Grafik außerhalb unseres Kreises liegen. QuickDraw 
erledigt diese (sonst wohl schwer zu realisierende) Aufgabe au- 
tomatisch. Der Text, der in Zeile 15 gezeichnet wird, sowie das 
Rechteck in Zeile 17 werden jetzt exakt auf die Clipping-Region 
beschränkt. 

Zeile 18 sorgt schließlich dafür, daß andere Teile unseres Pro- 
gramms nicht von unserer Clipping-Region betroffen werden, 
indem die Clipping-Region wieder auf die ursprüngliche Form 
gesetzt wird. Zum Schluß sollte man noch daran denken, daß 
wir ja zwei Handles (die Regions) alloziiert haben, die Speicher- 
platz in unserem Speicherbereich belegen. Da wir die Regions 
nicht mehr benötigen, geben wir sie mit Hilfe von DisposeRgn frei. 
Der von ihnen belegte Speicherplatz steht somit wieder zur Ver- 


fügung. 


Regions können (wie oben beschrieben) auch zum Zeichnen und 
zum Berechnen von Flächen verwendet werden. Die mathemati- 
schen Operationen, die zum Berechnen von Regions angewendet 
werden können, sind eine einzigartige Funktionalität von 








SectRgn 


Abb. 7-24 

Die Funktion SectRgn 
berechnet die Fläche, an 
der sich zwei Regions 
überschneiden. 


UnionRgn 


Abb. 7-25 

UnionRgn berechnet die 
gemeinsame Fläche 
zweier Regions. 


QuickDraw. Da Regions Flächen beschreiben, lassen sich die 
Gesetze der Mengenlehre hervorragend auf diese Strukturen 
anwenden; so kann man z.B. die Überschneidung zweier Regions 
oder auch die Addition beider Flächen berechnen. QuickDraw 
bietet für diese etwas ungewöhnliche, aber sehr nützliche Funk- 
tionalität von Regions unter anderem folgende Funktionen an: 


pascal void SectRgn (RgnHandle srceRgnA, 
RgnHandle srcRgnB, 
RgnHandle dstRgn); 





SectRgn berechnet die Überschneidung der Region sreRgnA mit 
der Region srcRgnB. Die resultierende Flächenbeschreibung wird 
in die Region dstRgn geschrieben. Diese Region muß vorher mit 
NewRgn angelegt worden sein. Es ist möglich, daß die Desti- 
nation-Region (dstRgn) einer der beiden Source-Regions (srecRgnA 
oder srcRgnB) entspricht. Dadurch ist es beispielsweise möglich, 
die gemeinsame Fläche von Region A und Region B zu berech- 
nen und das Ergebnis in Region A zu schreiben. 


pascal void UnionRgn ( RgnHandle srcRgnA, 
RgnHandle srcRgnB, 
RgnHandle astRgn); 





UnionRgn funktioniert, bezogen auf die Parameterübergabe, 
genauso wie SectRgn, berechnet jedoch die Fläche, die einer Ad- 





dition von sreRgnA und sreRgnB entspricht und schreibt diese 
in dstRgn. 


pascal void DiffRgn (RgnHandle srcRgnA, 
RgnHandle srcRgnB, 
RgnHandle dstRgn); 





DiffRgn berechnet die Differenz von sreRgnA und sreRgnB. 


Das Zeichnen einer Region ist vergleichbar mit dem Zeichnen 
eines Rechtecks oder eines Polygons. QuickDraw stellt für die- 
sen Zweck unter anderem die folgenden Zeichenfunktionen zur 
Verfügung: 


pascal void FrameRgn (RgnHandle ron); 


FrameRgn entspricht Funktionen wie FrameOval oder Frame- 
Rect, diese Funktion zeichnet die Umrandung einer Region. Da- 
bei werden sowohl äußere als auch innere Ränder gezeichnet. 
Ein innerer Rand einer Region ist beispiesweise dann vorhan- 
den, wenn die Fläche ein Loch hat. 


pascal void PaintRgn (RgnHandle rgn); 


Diese Funktion zeichnet die Fläche, die die Region beschreibt, in 
der aktuellen Farbe und dem aktuellen Pattern (Wie PaintRect). 


Nun folgt auch wieder ein kleines Beispiel, denn: Probieren geht 
schließlich über Studieren! Die folgende Funktion zeichnet die 
Schnittfläche zweier sich überlappender Kreise: 


| 7.6 Regions 





DiffRgn 


Abb. 7-26 

DiffRgn berechnet die 
Differenz zweier 
Flächen. 


FrameRgn 


PaintRgn 


Die Funktion 
PaintOvalRgn zeichnet 
die Fläche, an welcher 

sich zwei Kreise 
überschneiden. 
PaintOvalRgn verwendet 
Regions, um die Flächen 
der Kreise zu beschrei- 
ben bzw. den Bereich zu 
berechnen, welcher der 
Überschneidung der 
beiden Kreise ent- 
spricht. 


Abb. 7-27 

Die überschneidende 
Fläche zweier Kreise. 
Die angedeuteten Kreise 
beschreiben die Regions 
ovalRgnT und 
ovalRgn2. 





1: void PaintOvalSection (void) 


22.4 
3% RgnHandle ovalRgnl, ovalRgn2, 
intersectionRgn; 

4 Rect ovalRect; 

5: 

6: OpenRgn (); 

7: SetRect (&ovalRect, 0, 0, 100, 100); 
8: PaintOval (&ovalRect); 

9: ovalRgnl = NewRaon (); 

10: CloseRgn (ovalRgnl); 

Y1“% OpenRgn (); 

12: SetRect (&ovalRect, 50, 50, 150, 150); 
13: PaintOval (&ovalRect); 

14: ovalRgn2 = NewRan (); 

15: CloseRgn (ovalRgn2); 

16: intersectionRgn = NewRgn (); 
IE SectRgn (ovalRgnl, ovalRgn2, intersectionRgn); 
18: PaintRgn (intersectionßRgn); 

19: DisposeRgn (ovalRgnl); 
20: DisposeRgn (ovalRgn2); 
21: DisposeRgn (intersectionRgn); 
22: } 


Wir verwenden für die Implementierung drei Regions: ovalRgn1 
bzw. ovalRgn2 werden auf zwei einander überschneidende 
Kreisflächen gesetzt, die Region intersectionRgn beinhaltet nach 
dem Aufruf von SectRgn in Zeile 17 die Fläche, an der sich die 
beiden Kreisflächen überschneiden. Der Aufruf von PaintRgn in 
Zeile 18 zeichnet diese Fläche schließlich auf den Bildschirm. 
Wichtig ist auch hier wieder, daß nicht vergessen wird, die allo- 
ziierten Regions in den Zeilen 19-21 freizugeben, wir würden 
sonst Speicher verschwenden. 


0,0 50,0 





+ 
100,100 150,100 


7.7 Pictures 





7.7 Pictures 


Abb. 7-28 

Pictures werden zum 
Aufzeichnen von 
QuickDraw- 
Befehlssequenzen 
verwendet. Das 
korrespondierende 
Datenformat (PICT- 
Format) ist auf dem 
Macintosh eines der 
wichtigsten (und 
gebräuchlichsten) 
Bilddatenformate. 








Pictures beinhalten (wie der Name schon sagt) Bilder. Das 
Datenformat, welches Pictures zu Grunde liegt (das PICT-For- 
mat), stellt einen wichtigen Pfeiler der Kommunikation zwischen 
Macintosh-Programmen dar. Dieses Grafikdatenformat erlaubt 
es dem Benutzer beispielsweise, ein Bild in einem Grafikprogramm 
zu zeichnen und diese Grafik mittels Copy &Paste in einem Text- 
verarbeitungsprogramm einzufügen. Im Gegensatz zu anderen 
Bilddatenformaten (wie z.B. TIFF) erlauben QuickDraw-PICTs 
das Aufzeichnen und Abspulen objektorientierter Grafiken. Dies 
bedeutet, daß in einem PICT nicht die aus einer Reihe von 
QuickDraw-Befehlen resultierenden Punkte (Bit-Map) abgelegt 
werden, sondern die QuickDraw-Befehlssequenz, die zu dieser 
Grafik geführt hat. Durch diese Technik entstehen mehrere Vor- 
teile: 


1. Grafiken können skaliert gezeichnet werden, ohne daß dabei 
die Auflösung verloren geht. Abb. 7-29 zeigt den Unterschied 
zwischen einer skalierten, objektorientierten Grafik und einer Bit- 
Map-Grafik (z.B. TIFF). 
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Abb. 7-29 

Der Unterschied 
zwischen objekt- 
orientierter- und 
pixelorientierter Grafik. 
Werden pixelorientierte 
Grafiken skaliert, dann 
entstehen die bekannten 
'Treppen-Effekte'. Die 
Vergrößerung eines 
(objektorientierten) 
Pictures bewirkt keine 
Verschlechterung der 
Bildqualität, da Pictures 
die Informationen über 
die Grafikobjekte, 
anstelle der resultieren- 
den Grafik, enthalten. 


Objektorientiert Bit-Map 


O O 





2. Das PICT-Datenformat ermöglicht den objektorientierten 
Grafikaustausch zwischen zwei Grafikprogrammen. So ist es auf 
dem Macintosh beispielsweise möglich, eine Grafik, die aus zwei 
Kreisen besteht, von einem Grafikprogramm in ein anderes zu 
kopieren, und anschließend die beiden Kreise unabhängig von 
einander zu verändern. Da beide Programme dasselbe Daten- 
format benutzen, interpretiert das Zielprogramm die Grafik als 
Folge von einzelnen Grafikobjekten und kann dem Benutzer so 
die Möglichkeit geben, diese Objekte unabhängig voneinander 
zu verschieben, zu vergrößern etc. 


3. Durch die Vereinheitlichung des Grafikdatenformats ist es auf 
dem Macintosh ohne Programmieraufwand möglich, eine Gra- 
fik auf einem PostScript-Drucker oder auf einem Nadeldrucker 
auszugeben. Der Druckertreiber für den entsprechenden Druk- 
ker übersetzt das übergebene PICT-Datenformat dabei in die 
Datenstruktur, die der Drucker erwartet. Dadurch wird größt- 
mögliche Kompatibilität zwischen Programmen und Druckern 
erreicht (einheitliches Datenformat), und die Grafik erreicht auf 
den verschiedenen Druckern jeweils bestmögliche Qualität. So 
übersetzt der Druckertreiber eines PostScript-fähigen Druckers 
das zu druckende PICT in PostScript-Befehle. Der Druckertrei- 
ber eines Nadeldruckers schickt dem Drucker die aus dem PICT 
resultierende Bit-Map (Punkte-Grafik). 


Pictures werden in vielen Macintosh-Programmen neben ihrer 
Aufgabe, Grafiken auszutauschen, auch zum Darstellen von User- 
Interface-Elementen benutzt. So ist in vielen Programmen bei- 
spielsweise die Werkzeugleiste (Abb. 7-30) mit Hilfe eines PICTs 
gezeichnet. Der Vorteil liegt dabei darin, daß diese recht kompli- 











zierte Grafik nicht durch einzelne QuickDraw-Befehle (sozusa- 
gen zu Fuß) gezeichnet werden muß, sondern daß ein einziger 
Befehl genügt, um die gesamte Werkzeugleiste zu zeichnen. 
Das Aufzeichnen eines Pictures funktioniert ähnlich wie die De- 
finition einer Region. Zunächst wird QuickDraw mitgeteilt, daß 
alle folgenden QuickDraw-Befehle in ein Picture aufgezeichnet 
werden sollen. Anschließend werden die QuickDraw-Zeichen- 
befehle, die in dem PICT aufgezeichnet werden sollen, aufgeru- 
fen. Zum Schluß stoppt man die Aufzeichnung der QuickDraw- 
Zeichenbefehle. Soll das Picture dann an einer bestimmten Stelle 
in einer bestimmten Größe gezeichnet werden, so genügt ein Be- 
fehl, und QuickDraw wiederholt die in dem PICT aufgezeichne- 
ten Grafikbefehle. Dabei werden dieselben QuickDraw-Befehle 
aufgerufen, die während der Definition des Pictures aufgezeich- 
net wurden. QuickDraw führt dabei Transformationen der Pa- 
rameter für die Befehle durch. Soll das PICT beispielsweise grö- 
Ber gezeichnet werden, als es bei der Aufzeichnung war, so wer- 
den die Koordinaten der QuickDraw-Befehle mit dem entspre- 
chenden Faktor multipliziert, und die QuickDraw-Funktionen 
zeichnen das Bild vergrößert. 

Ein Picture ist (wie zu erwarten) eine Handle-basierte Struktur. 
Die korrespondierende Datenstruktur ist wie folgt deklariert: 


: struct Picture { 
short picSize; 
Rect picFrame; 


1 

2 

3: 

4: }; 
Dis 

6: typedef struct Picture *PicPtr, **PicHandle; 
Das Feld picSize eines Picture enthielt in früheren Versionen des 
Macintosh-Systems die Anzahl der Bytes, die ein Picture im 
Speicher belegte. Ein PICT war damals auf 32KB Daten beschränkt. 
Diese Einschränkung (und damit dieses Feld) ist in den heutigen 
Versionen jedoch nicht mehr gültig. Um die Größe eines Pictures 
im Speicher herauszufinden, kann man jetzt die Memory-Mana- 
ger-Funktion GetHandleSize benutzen, die als Ergebniswert die 
Größe des von dem Handle verwalteten Blocks (hier die Größe 


des Pictures) in Bytes zurückgibt. Das Feld picFrame stellt das 
umschließende Rechteck des Pictures, also die Original-Position 





Abb. 7-30 

Die ToolBox-Palette 
eines Grafikprogramms 
wird oft mit Hilfe eines 
Pictures gezeichnet. 


OpenPicture 


ClosePicture 


DrawPicture 


KillPicture 





und -Größe dar. Die in einem Picture aufgezeichneten QuickDraw- 
Befehle folgen nach dem Feld picFrame. 

Rund um Pictures stehen uns unter anderem die folgenden 
QuickDraw-Befehle zur Verfügung: 


pascal PicHandle OpenPicture ( 
const Rect *picFrame); 


OpenPicture alloziiert einen leeren PicHandle und startet die 
Aufzeichnung von QuickDraw-Zeichenbefehlen in ein PICT. Der 
von OpenPicture zurückgegebene PicHandle stellt nach Beendi- 
gung der Picture-Definition einen Handle auf die PICT-Daten (die 
Befehlssequenz) dar. Der Parameter picFrame gibt das um- 
schließende Rechteck des Bildes an. Während der Definition ei- 
nes Pictures haben QuickDraw-Befehle keine Auswirkungen auf 
den Bildschirm; sie werden ausschließlich zur Definition des PICTs 
verwendet. 


pascal void ClosePicture (void); 


Die Funktion ClosePicture beendet die Aufzeichnung von 
QuickDraw-Befehlen in das von OpenPicture angelegte PICT. 


Soll ein Picture gezeichnet werden, so kann man die Funktion 
DrawPicture verwenden. 


pascal void DrawPicture ( 
PicHandle myPicture, 
const Rect *dstRect); 


Diese Funktion erwartet in dem Parameter myPicture einen Handle 
auf eine QuickDraw-Befehlssequenz, wie sie mit OpenPicture bzw. 
ClosePicture definiert wird. Der Parameter dstRect gibt an, an 
welcher Stelle und in welcher Größe das Picture gezeichnet wer- 
den soll. Dieses Rechteck wird zur Berechnung der Transforma- 
tionswerte mit dem Rechteck verglichen, das bei OpenPicture 
angegeben wurde. 


pascal void KillPicture (PicHandle myPicture); 








KillPicture gibt den Speicherplatz, der von dem Picture belegt 
wird, zum Überschreiben frei. 


Das folgende Beispiel demonstriert die Verwendung eines PICTs, 
um eine Grafik an zwei verschiedenen Stellen in zwei verschie- 
denen Größen zu zeichnen: 





: void DrawTwoPictures 


{ 


(void) 


PicHandle myPicture; 

Rect myPicFrame, destRect, ovalRect; 
SetRect (&myPicFrame, 0, 0, 100, 100); 
myPicFrame = OpenPicture (&myPicFrame); 
SetRect (&ovalRect, 0, 0, 25, 25); 
PaintOval (sovalRect); 
SetRect (&ovalRect, 25, 
FrameOval (&ovalRect); 
ClosePicture (); 
SetRect (&destRect, 0, 0, 100, 100); 
DrawPicture (myPicture, &destRect); 
SetRect (sdestRect, 100, 100, 300, 
DrawPicture (myPicture, &destRect); 


25, 100, 100); 


300); 


0,0 





100,100 
4 





300,300 
—+ 


Um die Aufgabe zu erledigen, brauchen wir zunächst ein paar 
Variablen: myPicture wird die aufgezeichnete Befehlssequenz (das 





Die Funktion 
DrawTwoPictures 
erzeugt ein Picture, 
welches zwei Kreise 
enthält. Dieses Picture 
wird dann an zwei 
verschiedenen Stellen 
und in zwei verschiede- 
nen Größen gezeichnet. 


Abb. 7-31 

Die kleine Version der 
Grafik entspricht der 
Originalgröße und 
-Position der 
Grafikobjekte. Rechts 
unten wurde das Picture 
an einer anderen 
Position bzw. mit einer 
anderen Größe gezeich- 
net. Wichtig ist, daß die 
vergrößerte Version der 
Grafik keinen Qualitäts- 
verlust aufweist. 
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PICT) verwalten. Die Rechtecke myPicFrame und destRect 
werden zur Definition des Picture-Frames beim Eröffnen des 
Pictures bzw. des Ziel-Rechteckes beim Zeichnen des Pictures 
benötigt. Das dritte Rect (ovalRect) wird zum Zeichnen des Ovals 
verwendet. 
In Zeile 7 beginnt die Aufzeichnung der QuickDraw-Befehle, indem 
OpenPicture aufgerufen wird. Hier wird das vorher gesetzte Rect 
myPicFrame benutzt, um QuickDraw mitzuteilen, wie groß un- 
ser Picture sein wird. Alle QuickDraw-Zeichen-Befehle, die jetzt 
aufgerufen werden, dienen der Definition des Pictures; sie wer- 
den in der PICT-Datenstruktur, auf die myPicture verweist, se- 
quenziell abgelegt. Die beiden Zeichenbefehle in Zeile 9 und 11 
werden in unserem Picture aufgezeichnet, sie haben keine Aus- 
wirkungen auf den Bildschirm. Der Aufruf von ClosePicture in 
Zeile 12 beendet die Definition des Pictures und damit auch die 
Aufzeichnung der QuickDraw-Befehle. Nun brauchen wir nur 
noch mit Hilfe von DrawPicture dafür zu sorgen, daß unsere 
 aufgezeichnete Grafik auf dem Bildschirm gezeichnet wird. Die 
Zeilen 14 und 16 bewirken dies, wobei das Picture an zwei un- 
terschiedlichen Stellen in unterschiedlicher Größe gezeichnet wird. 
In Abb. 7-31 wird die resultierende Grafik gezeigt. Wichtig ist 
dabei, daß die vergrößerte Version unseres Bildes nicht an Auf- 
lösung verloren hat, die von anderen Systemen (z.B. MS-DOS 
oder Windows 3.0) bekannten "Treppen" in einer vergrößerten 
Grafik tauchen hier nicht auf ! 


7.8 Scrolling 


QuickDraw bietet Bausteine für die Implementierung von 
"scrollbaren" Bereichen. Diese grundlegende Funktionalität na- 
hezu aller Macintosh-Programme wird in Verbindung mit 
Scrollbars (Elemente des sogenannten "Control Managers") im- 
plementiert. Diese Scrollbars stellen das User-Interface des Scrollens 
dar. QuickDraw bietet die Funktionalitäten, die nötig sind, um 
den funktionellen Teil dieses oft benötigten User-Interface-Ele- 
mentes zu implementieren. 

Die Technik des Scrollens wird durch die Abarbeitung der fol- 
genden Schritte möglich: 


1. Verschieben des Fensterinhaltes mit der QuickDraw-Funkti- 
on ScrollRect. 

2. Verschieben des Koordinatensystems mit der QuickDraw- 
Funktion SetOrigin. 

3. Neuzeichnen der freigelegten Stellen. 


Mit Hilfe der Funktion ScrollRect kann man den Fensterinhalt 
verschieben. Diese Funktion übernimmt den für den Benutzer 
sichtbaren Teil des Scrollens, das Verschieben der Grafik. Die 
Funktion ScrollRect ist wie folgt deklariert: 


pascal void ScrollRect ( const Rect *r, 
short dh, 
short dv, 


RgnHandle updateRan); 


ScrollRect möchte als ersten Parameter das umschließende Rechteck 
des zu scrollenden Bereiches haben. Der Inhalt des durch den 
Parameter r spezifizierten Scroll-Bereichs wird um die Anzahl 
der Punkte verschoben, die in dh bzw. dv spezifiziert sind. Der 
Parameter dh gibt dabei die Anzahl der Punkte, um die horizon- 
tal gescrolled werden soll an, dv spezifiziert die vertikale "Scroll- 
Distanz". Beide Parameter können positiv, negativ oder auch 0 
sein. Dadurch ist es beispielsweise möglich, um 5 Punkte nach 
rechts und gleichzeitig um 20 Punkte nach unten zu scrollen. 
Nach dem Verschieben der Grafik mit Hilfe von ScrollRect gibt 
es einen Bereich, dessen Inhalt ungültig geworden ist, der neu 
gezeichnet werden muß.Wenn man anstelle von updateRgn eine 
Region übergibt, so ändert ScrollRect die Region so, daß sie den 
neuzuzeichnenden Bereich beschreibt. Diese Region kann dann 
verwendet werden, um den aktuellen Zeichenbereich mit Hilfe 
von SetClip auf diese Region zu beschränken. Anschließend kann 
man die gesamte Grafik neuzeichnen. Es werden dann nur die 
Teile der Grafik gezeichnet, die in dem neuzuzeichnenden Be- 
reich liegen. 


Die Implementierung der Scroll-Technik wäre mit hohem Auf- 
wand verbunden, wenn QuickDraw für diesen Zweck keine 
Komplettlösung bieten würde. Das Verschieben der Bildschirm- 
darstellung mit Hilfe der Funktion ScrollRect verschiebt nur den 


ScrollRect 


SetOrigin 


Abb. 7-32 

Nach einem Aufruf von 
SetOrigin (50, 50) hat 
die linke obere Ecke des 
Fensters die Koordina- 
ten (50, 50). Ein Aufruf 
von SetOrigin (0, 0) 
bringt den Koordinaten- 
systemursprung wieder 
auf seine Original- 
position zurück. 





Bildschirminhalt, nicht aber die Datenstrukturen, die für das 
Neuzeichnen der Grafik verwendet werden. Eine Grafikappli- 
kation wie MacDraw müßte die Koordinaten sämtlicher Grafik- 
datenstrukturen einer Grafik verändern, um die Datenstruktu- 
ren in Einklang mit der Bildschirmdarstellung zu bringen. Ein 
besserer Lösungsansatz ist es, das lokale Koordinatensystem des 
Fensters zu verschieben. Da sich alle QuickDraw-Befehle auf dieses 
Koordinatensystem beziehen, brauchen die Koordinaten der 
Grafikelemente nicht neu berechnet zu werden. Findet ein Update 
statt, so können die alten Koordinaten verwendet werden; da 
das Koordinatensystem verschoben worden ist, findet das Zeichnen 
nun an einer anderen Stelle statt. Mit Hilfe dieser Technik ist es 
sehr einfach (und schnell), eine komplexe Grafik zu scrollen. 

Die Funktion SetOrigin, mit deren Hilfe der Koordinaten- 
systemursprung verändert werden kann, ist wie folgt deklariert: 


pascal void SetOrigin (short h, short v); 


Die beiden Parameter (h und v) spezifizieren die neuen Koordi- 
naten des Koordinatensystemursprungs. Ein Aufruf dieser 
Funktion entspricht einem Verschieben sämtlicher Koordinaten, 
da sich alle QuickDraw-Befehle auf diesen Koordinatensystem- 
ursprung beziehen. SetOrigin verändert die absolute Position der 
Clipping-Region nicht, daher braucht das Clipping nach einem 
Aufruf von SetOrigin nicht neu gesetzt zu werden. 

Diese Funktion wird (wie beschrieben) meist in Verbindung mit 
der ScrollRect-Funktion eingesetzt. Nachdem das Koordinaten- 
system entsprechend des Scrollens verschoben worden ist, wird 
dann die Clipping-Region auf die von ScrollRect generierte Update- 
Region gesetzt, und die (selbstgeschriebene) Funktion zum 
Zeichnen des Fensterinhaltes aufgerufen. 





QuickDraw definiert einige Globals, die von der Applikation direkt 
verwendet werden können. Diese Globals sind automatisch de- 
finiert, wenn die Applikation QuickDraw verwendet, und wer- 
den in einem struct namens qd zusammengefaßt. Dieses struct 
enthält eine Reihe nützlicher (und wichtiger) Felder: 


1: extern struct { 

2: char privates[76]; 
3 long randSeed; 

4 BitMap screenBits; 
5% Cursor arrow; 

6: Pattern dkGray; 

1: Pattern ltGray; 

8: Pattern gray; 

9: Pattern black; 

10: Pattern white; 

11: GrafPtr thePort; 
12: }qd; 


Das struct beginnt mit einem Array (privates), der nur von 
QuickDraw selbst verwendet wird, dem privates-Feld. In dem 
nachfolgenden Feld (randSeed) kann der Wert der zuletzt gene- 
rierten Zufallszahl abgelesen werden (Funktion Random). 

Das Feld screenBits enthält Informationen über den Bildschirm. 
Die Informationen über den Bildschirm sind in einer Struktur 
vom Typ BitMap zusammengefaßt, einer Struktur, die norma- 
lerweise zur Verwaltung einer Bit-Map (Punktematrix) benutzt 


wird. 
1: struct BitMap { 
2 Ptr baseAddr; 
3 short rowBytes; 
4: Rect bounds; 
Ss: }3 
6: 
7: typedef struct BitMap BitMap; 


Da ein Bildschirm ebenfalls eine Bit-Map ist, eignet sich diese 
Datenstruktur auch, um Informationen über den Bildschirm zu 
verwalten. Das Feld baseAddr des BitMap-structs zeigt auf das 


Die QuickDraw-Globals 
sind automatisch 
definiert, wenn die 
‚Applikation QuickDraw 
verwendet. 


Eine Struktur vom Typ 
BitMap verwaltet eine 
Punktematrix. 


Das Feld thePort der 
QuickDraw-Globals zeigt 
auf die aktuell gültige 
Zeichenumgebung. 





erste Byte des Bildes, in diesem Falle zeigt dieser Pointer also in 
den Speicherbereich der Videokarte. Normalerweise interessiert 
man sich als echter Macintosh-Programmierer nicht für Video- 
karten und schreibt auch nicht direkt in den Video-Speicher. 
Ähnlich ergeht es uns mit dem Feld rowBytes, welches angibt, 
wieviele Bytes eine Zeile des Bildes belegt. Interessanter ist schon 
zu erfahren, wie breit bzw. wie hoch unser Bildschirm ist; Infor- 
mationen, die aus dem Rect bounds abgelesen werden können. 
Dieses Rechteck umschließt den gesamten Bildschirm. Da es auf 
dem Macintosh möglich ist, mehrere Bildschirme gleichzeitig an 
einen Rechner anzuschließen und diese Bildschirme wie einen 
großen zu verwalten, ist dieser Parameter mit Vorsicht zu be- 
handeln; sind mehrere Bildschirme angeschlossen, so beinhaltet 
das bounds-Feld das umschließende Rechteck aller Monitore, die 
verschiedenen Monitore verhalten sich wie ein zusammenhän- 
gender, überdimensionaler Bildschirm. Man kann also bei- 
spielsweise die initiale Fenstergröße nicht auf dieses Rechteck 
setzen, da die initiale Fenstergröße dem Hauptbildschirm ange- 
glichen werden sollte. 


Das Feld arrow der Variablen qd ist vom Typ Cursor. Diese 
Datenstruktur des Cursor-Managers enthält den auf dem Mac- 
intosh üblichen Pfeilcursor. Wenn das Programm eine längere 
Berechnung durchführt, so soll es (gemäß den "Human Interface 
Guidelines") den Cursor in eine Uhr verwandeln, um den Benut- 
zer davon zu informieren, daß das Programm zur Zeit nicht auf 
seine Eingaben reagieren kann. Soll der Cursor anschließend wieder 
auf die normale Form zurückgesetzt werden, so kann das Pro- 
gramm den Cursor arrow benutzen. Der entsprechende Aufruf 
ist: 


SetCursor (&qd.arrow); 


Die nachfolgenden Felder (dkGray bis white) können in Ver- 
bindung mit PenPat verwendet werden. Sie stellen vordefinierte 
Patterns dar, die direkt verwendet werden können (siehe 7.1 Punkte 
und Linien). 

Das letzte Feld des globalen structs (thePort) zeigt auf die aktu- 
ell gültige Zeichenumgebung. Die aktuelle Zeichenumgebung 





definiert das Koordinatensystem, die Clipping-Region und an- 
dere wichtige Zeichenattribute. Wenn zwischen verschiedenen 
Zeichenumgebungen umgeschaltet werden soll, so kann dies mit 
Hilfe der Funktion SetPort geschehen. SetPort ist wie folgt de- 
klariert: 


pascal void SetPort (GrafPtr port); 


Die Funktion SetPort schaltet die aktuelle Zeichenumgebung auf 
die Zeichenumgebung um, die dieser Funktion übergeben wird. 
Da die im folgenden beschriebenen GrafPorts die Grundlage für 
Windowsbilden, wird diese Funktion in der Regel dazu verwendet, 
die aktuelle Zeichenumgebung von einem Fenster auf ein ande- 
res umzuschalten. Das Koordinatensystem und alle anderen 
Zeichenattribute werden dann auf das entsprechende Fenster 
angepaßt. 


QuickDraw verwaltet und benutzt eine zentrale Datenstruktur, 
die die aktuelle Zeichenumgebung definiert. Diese Datenstruktur 
heißt GrafPort und beinhaltet sämtliche Informationen über den 
aktuellen Zustand der Zeichenumgebung, beispielsweise die 
aktuelle Farbe oder das aktuelle Muster für Zeichenoperationen 
sowie die Position des letzten LineTo-Befehls. Jedes Fenster be- 
sitzt seinen eigenen GrafPort, definiert also seine eigene Zei- 
chenumgebung. Sie werden selten auf die Felder dieser Daten- 
struktur zugreifen, da für die meisten Felder sogenannte "Access 
Functions" bestehen. Access-Functions sind Routinen, die eigentlich 
nichts anderes tun, als die übergebenen Parameter in den aktu- 
ellen GrafPort einzutragen, oder von dort zu lesen. Es ist trotz- 
dem sinnvoll, die einzelnen Felder dieser (recht komplexen) 
Datenstruktur vorzustellen, da ein Verständnis für die einzel- 
nen Felder eines GrafPorts bei der Fehlersuche sehr nützlich sein 
kann und dem allgemeinen Verständnis für die Funktionalität 
von QuickDraw dient. 


SetPort 


GrafPorts definieren die 
grafische Zeichen- 
umgebung (Koordi- 
natensystemursprung, 
Clipping-Region etc.). 
Jedes Fenster besitzt 
seinen eigenen GrafPort, 
definiert also seine 
eigene Zeichen- 
umgebung. Ein 
Macintosh-Fenster ist 
vergleichbar mit einem 
"virtuellen" Bildschirm. 





Ein GrafPort enthält die 
Felder, die den Zustand 
einer Zeichenumgebung 
reflektieren. In dieser 
Struktur sind beispiels- 
weise der aktuelle Pen- 
Pattern sowie die 
Glipping-Region 
enthalten. Viele 
QuickDraw-Funktionen 
greifen auf diese 
Datenstruktur zu, sie 
bilden sogenannte 
Access-Functions (z.B. 
PenPat oder TextFont). 





1: struct GrafPort { 

288 short device; 

3 BitMap portBits; 
4: Rect portRect; 
3% RgnHandle visRgn; 

6 RgnHandle clipRgn; 
7 Pattern bkPat; 

8: Pattern fillPat; 
95 Point pnLoc; 
10: Point pnSize; 
Lt short pnMode; 
12: Pattern pnPat; 
13% short pnVis; 
14% short txFont; 
152 Style txFace; 
16: char filler; 
14.8 short txMode; 
18: short txSize; 
19: Fixed spExtra; 
20: long fgColor; 
21: long bkColor; 
22% short colrBit; 
23: short patStretch; 
24: Handle picSave; 
25: Handle rgnSave; 
26: Handle polySave; 
27: ODProcsPtr qgrafProcs; 
28: }; 
29: 


30: typedef struct GrafPort GrafPort; 
31: typedef GrafPort *GrafPtr; 


Das erste Feld der Struktur (device) sollte für die meisten Pro- 
grammierer uninteressant sein, da es Informationen über die 
Videokarte enthält. Eine der wichtigsten Regeln der Macintosh- 
Programmierung lautete "Hardware-unabhängig programmie- 
ren", dieses Feld wird daher nicht näher beschrieben. 

Das nächste Feld (portBits) des structs ist wiederum ein struct. 
Dieser struct enthält Informationen über den gesamten Bildschirm 
(wie qd.screenBits). 

Das Feld portRect beschreibt das umschließende Rechteck der 
Zeichenumgebung in lokalen Koordinaten. Das heißt, daßtop und 
left dieses Rects normalerweise den Wert 0 enthalten. Anhand 
von bottom und right kann man feststellen, wieviele Punkte in 


einem Fenster zum Zeichnen zur Verfügung stehen. GrafPorts 
sind die mathematische Grundlage für Fenster, sie bestimmen 
die Zeichenumgebung eines Fensters. Das Feld portRect be- 
schreibt den Bereich eines Fensters, in den gezeichnet werden 
kann (den Fensterinhalt). Dieses Rechteck wird oft verwendet, 
um den gesamten Fensterinhalt zu löschen. 

Nun folgen zwei Region-Handles (visRgn und clipRgn). Das Feld 
visRgn beschreibt den Bereich der Zeichenumgebung. Wird ein 
Fenster von einem anderen überlagert, so beschreibt visRgn den 
verbleibenden (sichtbaren) Bereich des Fensters. Da QuickDraw 
beim Zeichnen sowohl auf die visRgn als auch auf die Clipping- 
Region achtet, kann es nie passieren, daß über die Grenzen eines 
Fensters hinausgezeichnet wird. 

In dem Feld clipRgn wird die (schon öfter erwähnte) Clipping- 
Region der grafischen Zeichenumgebung verwaltet. Benutztman 
die Funktion SetClip, um den Zeichenbereich einzuschränken, so 
legt SetClip die Kopie der übergebenen Region in dem Feld clipRgn 
der aktuellen Zeichenumgebung ab. Oft trifft man bei der Feh- 
lersuche auf den Fall, daß nicht gezeichnet wird, obwohl jede 
Menge QuickDraw-Befehle aufgerufen werden. In einem solchen 
Fall sollteman das Feld clipRgn des aktuellen GrafPorts mit Hilfe 
des Debuggers inspizieren und nachsehen, ob diese Clipping- 
Region nicht zu klein ist. 

Es folgen 7 Felder, die sich auf die aktuellen Zeichenattribute 
beziehen, soweit sie für das Zeichnen von Linien und Flächen 
nötig sind. So finden wir in dem Feld bkPat das aktuelle Muster 
für Lösch-Zeichenoperationen wie EraseRect. Dieses Feld wird 
durch einen Aufruf von BackPat gesetzt. 

Das Feld fillPat wird von (bisher noch nicht vorgestellten) FillRect- 
oder FillOval-Routinen verwendet. Diese Routinen stellen die 
Integration von PenPattern und PaintRect oder PaintOval in ei- 
nem Aufruf dar. 

Die letzte Position des QuickDraw-Zeichenstiftes wird in pnLoc 
festgehalten. Dieses Feld enthält also das zuletzt mit MoveTo, 
LineTo oder anderen QuickDraw-Funktionen angesteuerte Ko- 
ordinatenpaar. 

Das Feld pnSize beinhaltet die aktuelle Zeichenstifthöhe und 
-breite, die man mit der PenSize-Funktion verändern kann. 


Die Region visRgn und 
clipRgn schränken den 
Bereich ein, in welchem 
QuickDraw-Zeichen- 
funktionen agieren 


- können. 


Die QuickDraw-Funktion 
EraseRect "löscht" ein 
Rechteck, indem sie 
dieses Rechteck mit 
dem Hintergrundmuster 
(bkPat) übermalt. 


Der aktuelle Transfer-Mode für Zeichenoperationen wird indem 
Feld pnMode festgehalten. Haben wir beispielsweise PenMode 
(patXOr) aufgerufen, so beinhaltet dieses Feld den entsprechen- 
den Wert. 

Das Feld pnPat enthält das Zeichenstiftmuster, mit dem die 
nächste Zeichenoperation zeichnen wird (z.B. LineTo, FrameRect 
oder PaintRect). Dieses Feld wird durch den Aufruf der Funk- 
tion PenPat gesetzt. 

An dem Feld pnVis kann abgelesen werden, ob der QuickDraw- 
Zeichenstift gerade gesenkt (ShowPen) oder angehoben (HidePen) 
ist, bzw. in welcher Höhenstufe er sich befindet. 

Das Feld txFont gibt die mit TextFont eingestellte Schriftfamilie 
an, und txFace reflektiert die mit TextFace eingestellten Schrift- 
stile. 

Das Feld filler ist nicht benutzt und dient nur dem Zweck, die 
Adresse des nächsten Feldes in den "Word-Boundaries" zu hal- 
ten; d.h., daß das nächste Feld wieder bei einer geraden Adresse 
beginnt. Dies wird nötig, da das vorangegangene Feld (txFace) 
ein Byteistund damit das nächste Feld bei einer ungeraden Adresse 
beginnen müßte. Die 68000-Familie "mag" es wesentlich lieber, 
wenn Adressierungen in den sogenannten "Word Boundaries" 
liegen, die Adressierung wird dadurch wesentlich schneller. Diese 
"fillers" sind immer dort zu finden, wo ein Feld einer Datenstruktur 
nur ein Bytelang ist, damit nachfolgende Felder wieder auf Word- 
Boundaries anfangen. 

QuickDraw besitzt spezielle Attribute für das Zeichnen von Text, 
die unabhängig von den Pen-Attributen verwaltet werden. An 
txMode erkennt QuickDraw, in welchem Transfer-Mode der 
nächste Text gezeichnet werden soll. Text-Zeichenroutinen wer- 
den also nicht von Aufrufen wie PenMode beeinflußt. 

Die eingestellte Schriftgröße finden wir in txSize wieder, das Feld 
spExtra kann für die Erzeugung von Blocksatz verwendet wer- 
den. 

Die nachfolgenden drei Felder (fgColor, bkColor und colrBit) 
beschäftigen sich mit der Erzeugung von Farbe bei QuickDraw- 
Aufrufen wie PaintRect oder FrameRect. Die Farbmöglichkeiten 
von QuickDraw sind jedoch so eingeschränkt, daß sie hier nicht 
weiter beschrieben werden. Professionelle Farbverarbeitung ist 


nur mit einer Erweiterung von QuickDraw, dem Color-QuickDraw 
möglich. Color-QuickDraw wird unter 7.11 näher beschrieben. 
Das Feld patStretch wird QuickDraw-intern beim Drucken ver- 
wendet und braucht nicht näher beschrieben zu werden. 

Die letzten drei Felder (picSave, rgnSave und polySave) wer- 
den während der Definition eines Pictures, einer Region bzw. 
eines Polygons verwendet. So enthält das Feld polySavenach dem 
Öffnen eines Polygons mit Hilfe von OpenPoly den in Konstruk- 
tion befindlichen PolyHandle. AlleMoveTo-bzw. LineTo-Befehle 
hängen ihre Koordinaten an dieses Polygon an. Normalerweise 
enthält dieses Feld den Wert NULL, was bedeutet, daß kein Po- 
lygon aufgezeichnet wird. Soll die Definition eines Polygons 
zeitweise ausgesetzt werden, so merkt man sich den PolyHandle 
und setzt das Feld polySave auf NULL. Wenn die Definition des 
Polygons wieder aufgenommen werden soll, so setzt man den 
gemerkten PolyHandle wieder in polySave ein, und LineTo- 
Befehle werden ihre Koordinaten wieder an dieses Polygon an- 
hängen. Diese Technik wird bei vielen Grafikprogrammen ver- 
wendet, wenn der Benutzer ein Polygon zeichnen will. Die Defi- 
nition des Polygons geschieht (aus Sicht des Programmierers) 
natürlich mit OpenPoly bzw. mit LineTo-Befehlen. Die User-In- 
terface-Standards schreiben vor, daß jeder Eckpunkt des Poly- 
gons mit Hilfe eines neuen Mausklicks definiert wird. Solange 
der Benutzer nur die Maus bewegt, wird ein "Gummiband" vom 
letzten Punkt zu der aktuellen Mausposition gespannt. Dieses 
Gummiband wird mit Hilfe von LineTo-Befehlen bzw. eines auf 
patXor gesetzten Pen-Modes implementiert. Da die Koordina- 
ten dieser Gummiband-Linien nicht in die Definition des Poly- 
gons mit aufgenommen werden sollen, wird die Definition des 
Polygons mit der oben beschriebenen Technik einfach ausgesetzt, 
solange das Gummiband gezeichnet wird. 

Ähnliche Anwendungsbereiche lassen sich auch für dasrgnSave- 
Feld eines GrafPorts finden. In Bit-Map-orientierten Program- 
men (wie z.B. MacPaint oder PhotoShop) kann die Definition ei- 
ner "Lasso-Region" unter Verwendung der gerade beschriebenen 
Technik implementiert werden. Solche "Lasso-Regionen" wer- 
den dann dazu verwendet, einen Bereich einer Bit-Map-Grafik 
auszuschneiden oder zu kopieren. 





Sämtliche QuickDraw- 
Zeichenfunktionen 
lassen sich auf einige 
wenige (aber universel- 
le) Routinen zurückfüh- 
Ten. 


Color-QuickDraw 
erweitert die Fähigkeiten 
von QuickDraw um 
Routinen und Daten- 
strukturen, welche eine 
professionelle Farbver- 
arbeitung ermöglichen. 


Das letzte Feld grafProcs wird von den meisten Macintosh-Pro- 
grammen nicht benutzt, es wird der Vollständigkeit halber 
trotzdem beschrieben. Dieses Feld ist normalerweise NULL. Es 
kann jedoch einen Pointer auf einen QDProcs-struct enthalten. 
Dieser struct kann dann wiederum Pointer auf Funktionen ent- 
halten, die die Standard-QuickDraw-Funktionen überlagern oder 
ausschalten. Sämtliche QuickDraw-Zeichenfunktionen lassen sich 
auf einige wenige (aber universelle) Routinen zurückführen. Die 
in diesem Kapitel vorgestellten Zeichenroutinen rufen alle diese 
universellen Standard-Routinen auf. Die bisher beschriebenen 
Grafikfunktionen bieten uns nur ein vereinfachtes Interface. Möchte 
man das Verhalten der universellen Low-Level-QuickDraw- 
Routinen verändern, so kann man in dem grafProcs-Feld einen 
Pointer auf ein QDProcs-struct installieren. In diesem struct trägt 
man dann (anstelle der Funktions-Pointer auf die Standard- 
QuickDraw-Zeichenfunktionen) Pointer auf selbstgeschriebene 
Funktionen ein. Sämtliche QuickDraw-Routinen landen damit 
schließlich bei den selbstdefinierten "Bottle-Neck"-Routinen. Diese 
ungewöhnliche Technik wird hauptsächlich von objektorientierten 
Grafikprogrammen wie MacDraw oder Canvas zum "Parsen" von 
importierten Pictures verwendet. Die Technik des Picture-Parsens 
wird von diesen Programmen dazu verwendet, die Einzel-Ob- 
jekte, die sich in einem importierten PICT befinden, herauszu- 
holen. Dadurch wird der objektorientierte Grafikdatenaustausch 
zwischen diesen Grafikprogrammen möglich. 


Apple bemüht sich seit jeher erfolgreich, sämtliche Betriebssystem / 
ToolBox-Funktionalitäten auf der gesamten Rechnerpalette ein- 
heitlich zu gestalten, um uns Programmierern (und damit auch 
den Benutzern) das Leben leichter zu machen. So existieren na- 
hezu alle ToolBox-Routinen in identischer Form auf allen Rech- 
nern, sei es ein 68000- oder 68040-bestücktes System. Die einzige 
wichtige Ausnahme liegt in der Implementierung von QuickDraw. 
Es existieren zwei verschiedene QuickDraw-Versionen, das Ori- 
ginal-QuickDraw und das neuere, erweiterte Color-QuickDraw. 
Color-QuickDraw enthält die gesamte Funktionalität des Origi- 





nal-QuickDraws, bietet jedoch Möglichkeiten zur professionel- 
len Farbdarstellung und -verarbeitung. Im Gegensatz zu ande- 
ren Betriebssystem-Erweiterungen, die im Laufe der Geschichte 
des Macintosh-Betriebssystems eingeführt wurden, sind die Er- 
weiterungen von QuickDraw zu Color-QuickDraw nicht auf äl- 
teren Generationen der Macintosh-Produktfamilie einsetzbar. 
Color-QuickDraw ist nur auf Macintosh-Systemen mit einem 68020, 
68030- oder 68040-Prozessor einsetzbar. Nur auf diesen Rech- 
nern stehen uns professionelle Routinen zur Farbverarbeitung 
zur Verfügung. In bezug auf die Kompatibilität mit der Macin- 
tosh-Familie stehen uns die folgenden Optionen zur Auswahl: 


1. Genereller Verzicht auf Farbdarstellung. 

Der sicherste (und einfachste) Weg ist eindeutig der Verzicht auf 
Color-QuickDraw-Funktionalitäten. Die meisten Programme 
kommen auch ohne die Darstellung von Farbe aus. Der Vorteil 
hier: 100prozentige Kompatibilität ohne zusätzlichen Aufwand. 


2. Das Programm erkennt, ob der Rechner Color-QuickDraw- 
fähig ist und benutzt Farbmanipulationsroutinen nur auf den 
Color-QuickDraw-fähigen Rechnern. Auf 68000er Macintosh- 
Computern verwendet das Programm keine Farbdarstellung. 
Kommt das Programm auf keinen Fall ohne Farbdarstellungen 
aus, so ist der bessere (jedoch aufwendigere) Weg die interne 
Teilung des Programms in QuickDraw- und Color-QuickDraw- 
Routinen. Idealerweise entscheidet das Programm zur Laufzeit, 
welche Darstellungsroutinen aufgerufen werden. Dadurch ist (für 
den Benutzer) ein und dasselbe Programm auf der gesamten Mac- 
Familie einsetzbar, nur daß auf manchen Macs bestimmte Funk- 
tionalitäten des Programms nicht verfügbar sind. Eine Unterteilung 
in zwei Programmversionen (wie dies auch von einigen Herstel- 
lern getan wird) ist etwas User-unfreundlich und komplizierter 
zu entwickeln bzw. weiterzuentwickeln, da ständig zwei Ver- 
sionen gepflegt werden müssen. 


3. Das Programm verzichtet auf die Kompatibilität zur 68000er 
Reihe der Macintosh-Familie und setzt ausschließlich auf Farb- 
darstellung. 


Color-QuickDraw ist nur 
auf Macintosh-Rechnern 
mit 68020-, 68040-, 
oder 68040-Prozessor 
lauffähig. 


Der Verzicht auf Color- 
QuickDraw bewirkt 
100prozentige Kompati- 
bilität. 


Viele Programme sind 
so aufgebaut, daß sie 
erkennen, ob der 
Rechner, auf dem sie 
laufen, ein CGolor- 
QuickDraw-Macintosh 
ist. Diese Programme 
halten alle internen 
Zeichenroutinen so 
flexibel, daß sie sich an 
die jeweilige Umgebung 
anpassen. 


Einige Programme 
verzichten auf die 
Kompatibilität mit den 
Macintosh-Rechnern, 
die auf dem 68000- 
Prozessor basieren. 


Die letzte Option ist (ähnlich der ersten) eine einfache Möglich- 
keit, die jedoch auch einige Einschränkungen mit sich bringt. 
Schränkt Option Nummer 1 die Funktionalität des Programms 
ein, so schränkt Option Nummer 3 den Käuferkreis ein. Ein 
Macintosh Classic- Benutzer muß sich bei dieser Version mit der 
Mitteilung "Dieses Programm ist nur auf farbfähigen Macintosh- 
Computern lauffähig" zufrieden geben. 


Alle drei Optionen haben Vor- und Nachteile, die je nach Projekt 
bzw. Zielmarkt und Arbeitsaufwand sorgfältig abgewogen wer- 
den müssen. 

Sollen die Möglichkeiten von Color-QuickDraw genutzt werden, 
so wird anstelle des bisher beschriebenen QuickDraw-GrafPorts 
ein Color-GrafPort (CGrafPort) verwendet. Diese CGrafPort- 
Struktur enthält im wesentlichen dieselben Felder wie ein GrafPort, 
es existieren jedoch im Gegensatz zum Original-QuickDraw- 
GrafPort sehr genaue Farbinformationen, die beim Zeichnen von 
QuickDraw-Objekten eingesetzt werden können. 
Color-QuickDraw wird hier nicht näher beschrieben, da diese 
Funktionalität von den meisten Programmen nicht benötigt wird. 
Für die Erstellung der ersten kleinen Macintosh-Programme bietet 
das hier beschriebene Standard-QuickDraw genügend Möglich- 
keiten. Falls Sie in Ihrer Applikation von Anfang an Farbunter- 
stützung einbauen wollen, so wird auf die Standard-Dokumen- 
tation "Inside Macintosh Vol.V" verwiesen, die eine detaillierte 
Beschreibung von Color-QuickDraw enthält. 





Teil 3 Einstieg in die 
Praxis 


Dieser Teil des Buches stellt den Einstieg in die Praxis der Mac- 
intosh-Programmierung dar. In diesem Teil wird die Praxis 
überwiegen. Die vorgestellten ToolBox-Elemente, d.h. die Manager 
und ihre Routinen, sind so ausgewählt, daß sie einen möglichst 
schnellen Einstieg in die Macintosh-Programmierung erlauben. 
Trotzdem wird in den folgenden Kapiteln immer wieder Hinter- 
grundwissen vermittelt, um den Gesamtzusammenhang zwischen 
den ToolBox-Elementen herzustellen. 


Kapitel 8 gibt zunächst einen Einstieg in die Entwicklungsum- 
gebung MPW-Shell, die in den folgenden Kapiteln zur Erzeu- 
gung der Beispiel-Programme verwendet wird. Dieses Kapitel 
beschränkt sich auf die wesentlichen Elemente der MPW-Shell 
und ermöglicht den schnellen Einstieg in diese komplexe Umge- 
bung. 


Kapitel 9 beschreibt die Erzeugung und Verwaltung von Fenstern. 
Dieses Kapitel stellt einen der wichtigsten Grundpfeiler der fol- 
genden Kapitel dar. Der schrittweise Aufbau einer Rahmenap- 
plikation beginnt mit der hier vorgestellten Fensterverwaltung. 
Am Ende dieses Kapitels wird die erste Experimentierplattform, 
das Programm MINIMUM, vorgestellt. 


Kapitel 10 fügt einen weiteren essentiellen Baustein der Macin- 
tosh-Programmierung in die vorgestellten Elemente ein. Dieses 
Kapitel beschreibt die Verwaltung von Events mit Hilfe der Main- 











Event-Loop und demonstriert diese Basistechnik anhand eines 
stark erweiterten MINIMUM-Programms. 


Kapitel 11 erweitert die Basis-Bausteine um den Baustein der 
Menüverwaltung. Dieses Kapitel beschäftigt sich mit der Kon- 
zeption, der Installation und der Verwaltung von Menüs in ei- 
ner Macintosh-Applikation. Die Anwendung der Menütechnik 
wird anhand eines erweiterten MINIMUM-Beispiel-Programms 
demonstriert. 


Kapitel 12 stellt die Verwendung von Controls in einer Macin- 
tosh-Applikation vor. Hier werden Elemente wie z.B. Scrollbars 
in die Rahmenapplikation mit eingebracht. Am Ende dieses Ka- 
pitels wird die Basis-Applikation MINIMUM so erweitert, daß 
sie Scrollbars verwendet, um dem Benutzer die Möglichkeit zu 
geben, den Fensterinhalt zu verschieben. 


Kapitel 13 gibt eine Einführung in die Erzeugung und Verwal- 
tung von Dialogen auf dem Macintosh. Im Laufe des Kapitels 
wird der Dialog-Manager vorgestellt, welcher für die Verwal- 
tung von Dialogen zuständig ist. Zum Schluß wird wieder eine 
erweiterte Version von MINIMUM vorgestellt; diesmal erhält die 
Applikation einen Dialog. 


Kapitel 14 bildet den Abschluß in der Reihe der Beispielpro- 
gramme, indem das Beispielprogramm SKELETON vorgestellt 
wird. Dieses Programm baut auf den vorangegangenen Bei- 
spielprogrammen auf und vervollständigt die Fähigkeiten. 
SKELETON ist ein Rahmenprogramm, welches als Basis für die 
Entwicklung komplexer Projekte dienen kann. 


Kapitel 15 gibt schließlich einen Überblick über die Dokumenta- 
tion. Hier wird der Aufbau und Inhalt der "Inside Macintosh"- 
Dokumentation erläutert. Dieses Kapitel gibt weiterhin wichtige 
Hinweise auf weitergehende Informationsquellen, die bei der 
Entwicklung eines Macintosh-Programms nützlich sind. 


Kapitel 8 


Die Entwicklungs- 
umgebung MPW- 
Shell 


Dieses Kapitel gibt eine Einführung in die MPW-Shell (eine 
Entwicklungsumgebung für den Macintosh). Die MPW-Shell 
wurde als Entwicklungssystem für die in diesem Buch vorge- 
stellten Beispiel-Programme ausgewählt. Die Einführung in die 
Entwicklungsumgebung beschränkt sich auf ein Minimum, um 
möglichst schnell zur Vorstellung kompletter Beispiel-Programme 
zu kommen, bzw. mit eigenen Experimenten beginnen zu können. 


Die MPW-Shell ist eine der professionellsten Entwicklungsum- 
gebungen, die auf dem Macintosh existieren. Dieses Entwick- 
lerwerkzeug bietet eine UNIX-ähnliche Kommando-Oberfläche 
in Kombination mit einer Macintosh-üblichen Menügesteuerten 
Programmstruktur. Sie enthält einen komfortablen Shell-Editor, 
eine Scripting-Language zur Automatisierung sowie mehrere 
Compiler und einen Linker. In diesem sehr umfangreichen Paket 
befindet sich weiterhin ein Low-Level-Debugger (MacsBug) so- 
wie ein sehr mächtiger Source-Level-Debugger (SADE). 

Es gibt (wie bei der Wahl der Programmiersprache) geteilte Mei- 
nungen über die Entwicklungsumgebungen. Die Verfechter der 
MPW-Shell loben ihre Flexibilität und Erweiterbarkeit, ihre Gegner 
prangern die komplizierte Benutzung der kryptischen Oberflä- 
che an. Ich möchte mir an dieser Stelle kein endgültiges Urteil 
über die verschiedenen Entwicklungsumgebungen erlauben, 
werde zur Erstellung der Beispiel-Programme jedoch die MPW- 


Shell benutzen. Entscheiden Sie sich für die Benutzung einer al- 137 
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DieMPW-Shell 


ternativen Entwicklungsumgebung wie z.B. Think C, so können 
die Quelltexte der Beispiel-Programme (mit kleinen Änderun- 
gen) auch mit dieser Entwicklungsumgebung übersetzt werden. 
Die MPW-Shell ist die offizielle Entwicklungsumgebung für den 
Macintosh. Obwohl sie nicht die einzige professionelle Entwick- 
lungsumgebung ist, hat sie mehrere Vorteile gegenüber anderen 
Entwicklungsumgebungen. Die wichtigsten Vorteile dieser Ent- 
wicklungsumgebung sind: 


1. Die MPW-Shell ist von Apple. 

Apple selbst entwickelt neue Versionen des Macintosh Betriebs- 
systems mit Hilfe dieser Entwicklungsumgebung. Es ist davon 
auszugehen, daß sich dieses Werkzeug stets auf dem neuesten 
Stand der Betriebssystementwicklung befindet. 


2. Diese Entwicklungsumgebung ist aufgrund ihrer Konzeption 
Die MPW-Shellist besonders gut für größere Projekte geeignet, an denen mehrere 
besonders gutfür Programmierer zur gleichen Zeit arbeiten. 

größere Projekte Sie bietet Mechanismen und Werkzeuge zur automatischen Ver- 
geeignet, an denen sion-History-Erstellung. Dies bedeutet, daß die gesamte Projekt- 
mehrere Programmierer Historie (alle jemals erstellten Versionen der Quelltexte) in einer 
arbeiten. Datenbank gehalten werden. Dieses Konzept ermöglicht es, nach 
einer Fehl-Entwicklung zu einem genau definierten Entwick- 
lungsstand eines Quelltextes zurückzukehren. Die MPW-Shell 
bietet weiterhin Mechanismen, die der üblichen Verwirrung bei 
Gruppenarbeiten an einem Projekt vorbeugen. Werden die 
Quelltexte in einer Projekt-Datenbank auf einem File-Server ab- 
gelegt, so können alle Mitarbeiter mit denselben Quelltexten ar- 
beiten. Die Mechanismen achten dabei darauf, daß nicht zwei 
Programmierer gleichzeitig an ein und demselben Quelltext ar- 

beiten. 


3. Die Entwicklungsumgebung MPW-Shell bietet Mechanismen 
zur Automatisierung. 
Automatisierung mit Die Scripting-Language der MPW-Shell ermöglicht die Automa- 
Hilfe von Scripts isteine tisierung von ständig wiederkehrenden Prozessen bei der Ent- 
der wichtigsten Vorteile wicklung eines Macintosh-Programms (vergleichbar mit Scripts 
der MPW-Shell. unter UNIX). 
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4. Die MPW-Shell besitzt eine Open Architecture. 

Durch ein universell gehaltenes Object-Code-Format können 
verschiedene Programmiersprachen in einem Projekt gemischt 
werden. 


Die Open Architecture der MPW-Shell ermöglicht es, ein Pro- 
gramm mit Hilfe von mehreren Programmiersprachen zu erstellen. 
Bestimmte Probleme lassen sich beispielsweise nur in Assem- 
bler (Maschinensprache) lösen, der Hauptteil eines Macintosh- 
Programms besteht jedoch aus C, Pascal oder Modula II. Ein 
universell gehaltenes Object-Code-Format ermöglicht es dem 
Linker, Object-Code-Moduln, die aus unterschiedlichen Pro- 
grammiersprachen stammen, zu einem Programm zusammen- 
zubinden. 

Ein offensichtlicher Vorteil der Open Architecture liegt darin, 
daß man sich nicht auf eine Programmiersprache festlegen muß. 
Wechselt man im Laufe der Programmierkarriere einmal von Pascal 
nach C oder C++, so kann man bereits fertiggestellte Programm- 
teile in der ursprünglichen Programmiersprache belassen. Neue 
Teile werden dann einfach in einer anderen Programmierspra- 
cheimplementiert und zusammen mit denälteren Teilen zu einem 
Programm zusammengebunden (gelinkt). 

Da das Object-Code-Format lizensierbar ist, bieten einige Dritt- 
anbieter alternative Programmiersprachen bzw. Compiler für die 
MPW-Shell an. Diese Compiler lassen sich gemeinsam mit den 
von Apple mitgelieferten Programmiersprachen einsetzen; die 
von diesen Compilern erzeugten Moduln können mit anderen 
Moduln zu einem Programm zusammengebunden werden. 
Durch die universelle Object-Code-Struktur ist es im Gegensatz 
zu anderen Entwicklungsumgebungen möglich, während des 
Debuggens der Applikation zwischen den verschiedenen Pro- 
grammiersprachen hin- und herzuschalten. Der Source-Level- 
Debugger SADE ist in der Lage, sowohl Pascal als auch C bzw. 
Assembler-Source-Texte symbolisch zu debuggen. 

Die Programmiersprachen, die Apple für die MPW-Shell anbietet, 
sind: 





Ein Macintosh- 
Programm kann aus 
mehreren Moduln 
bestehen, die in 
unterschiedlichen 
Programmiersprachen 
geschrieben worden 
sind. 


Der Linker kann Object- 
Code-Moduln, die in 
unterschiedlichen 
Programmiersprachen 
erstellt worden sind, zu 
einem Programm 
zusammenbinden. 
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Es gibt eine Vielzahl an 
Programmiersprachen, 
die für die MPW-Shell 
angeboten werden. 


Die Scripting-Language 
bietet die Möglichkeit, 
immer wiederkehrende 
Prozesse zu automati- 
sieren. 





« Assembler 

e Pascal (Object-Pascal) 

°.c 

e C++ (C Front 2.0 von AT&T) 
 Lisp (common Lisp) 


Drittanbieter bieten unter anderem die folgenden Programmier- 
sprachen zur Integration in die MPW-Shell an: 


e Turbo Pascal 
* Modula II 

« Fortran 77 

« ADA 


Die Scripting-Language der MPW-Shell ist zur Automatisierung 
immer wiederkehrender Prozesse während der Erstellung einer 
Macintosh-Applikation gedacht. Diese Scripting-Language ist 
vergleichbar mit der Scripting-Language von UNIX-Shells. Es 
ist eine Art Programmiersprache, mit der die gesamte Funktio- 
nalität der MPW-Shell gesteuert werden kann. Nun ist die 
kryptische Scripting-Language der MPW-Shell nicht jedermanns 
Sache (gerade Macintosh-Gewöhnte werden sich an graue Vor- 
zeiten unter DOS oder UNIX erinnert fühlen). Die Möglichkei- 
ten zur Automatisierung müssen zum Glück nur dann verwen- 
det werden, wenn dies nötig wird; man kann ein Macintosh- 
Programm auch ohne Kenntnisse dieser Scripting-Language er- 
stellen. Bei größeren Projekten erweist sich die Möglichkeit zur 
Automatisierung jedoch als große Hilfestellung und als angenehme 
Möglichkeit der MPW-Shell. 

Eine interessante Möglichkeit dieser MPW-eigenen Program- 
miersprache liegt darin, daß man mit ihrer Hilfe die MPW-Shell 
selbst erweitern kann. Es ist mit bestimmten Befehlen möglich, 
neue Menüs zusätzlich zu den Standard-Menüs der MPW-Shell 
hinzuzufügen. An diese "persönlichen" Menüs hängt man üb- 
licherweise Scripts, die bestimmte Prozesse automatisieren. Ein 
Beispiel für ein solches Menü wäre ein selbstdefinierter Menü- 








punkt namens "Search ToolBox...". Wird dieser Menüpunkt 
ausgewählt, so wird ein bestimmtes Script ausgeführt. In diesem 
Script wird mit Hilfe von bestimmten Scripting-Language-Befehlen 
nach einem Text gefragt. Ist der Text eingegeben, so durchsucht 
das Script die Interface-Dateien sämtlicher ToolBox-Manager nach 
dem eingegebenen Begriff... ein Automatismus, der sich als sehr 
nützlich erweisen kann. 

An dieser Stelle wird nicht weiter auf die Scripting-Language 
der MPW-Shell eingegangen, da sie (wie gesagt) nicht unbedingt 
nötig ist, um ein Macintosh-Programm zu erstellen. In der 
Lernphase sollte man sich lieber mit der ToolBox, mit Quick- 
Draw bzw. mit dem Betriebssystem auseinandersetzen, als zu 
versuchen, die schier unerschöpflichen Automatisierungsmö- 
glichkeiten der MPW-Shell zu entdecken. Die Scripting-Language 
ist ein Bereich, um den man sich erst dann kümmern sollte, wenn 
konkret an größeren Projekten gearbeitet wird und die ersten 
Wünsche nach Automatismen laut werden. 


Die MPW-Shell bietet, vergleichbar mit UNIX-Systemen, eine 
Vielzahl von Befehlen. Diese Befehle, die oft in Scripts verwen- 
det werden, sind als eigenständige, kleine Unterprogramme der 
MPW-Shell implementiert. Sie werden von der MPW-Oberfläche 
aus aufgerufen und kehren nach getaner Arbeit wieder zurück. 
Das Verhalten bzw. der Aufruf eines Tools ist mit dem Aufruf 
eines UNIX- oder DOS-Kommandos vergleichbar. Diese Tools, 
von denen etwa 80 verschiedene existieren, bieten die verschie- 
densten Möglichkeiten. Unter diesen Tools sind unter anderem 
die folgenden zu finden: 


Search - durchsucht eine oder mehrere Textdateien nach einem 
Textmuster und gibt die gefundenen Zeilen in das Worksheet 
(die Console der MPW-Shell) aus. 


TextCompare - vergleicht zwei Versionen einer Textdatei und zeigt 
die Unterschiede auf. 





Die Scripting-Language 
wird in der Regel erst 
bei der Realisierung 
komplexerer Projekte 
verwendet. 


Die Tools bilden den 
Befehlsumfang der 
MPW-Shell. 
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Resedit ist ein grafi- 
scher Resource-Editor, 
mit dem Resources 
angelegt, gelöscht und 
modifiziert werden 
können. 


Open/Close - öffnet bzw. schließt eine Textdatei. 


Rez - übersetzt eine Resource-Description-Datei (wird später er- 
klärt). 


Delete - löscht eine Datei. 
usw... 


Diese Tools bilden praktisch den Befehlssatz der Scripting- 
Language, sie sind der Teil eines Scripts, der wirklich etwas tut. 
Ein Script ist lediglich eine Aneinanderreihung konditionaler 
Aufrufe von Tools. 


8.4 Erstellen von Resources 


Das Erstellen von Resources ist eine wichtige Aufgabe, eine Vor- 
aussetzung für die Programmierung einer echten Macintosh- 
Applikation. Resources können auf mehrere Arten und Weisen 
erstellt werden. Im Nachfolgenden werden drei verschiedene 
Möglichkeiten aufgezeigt, wie Resources erstellt werden können, 
bzw. wo die Vor- und Nachteile der jeweiligen Methode liegen. 


8.4.1 ResEdit 


Mit Hilfe des zur MPW-Shell gehörenden Programms ResEdit 
lassen sich recht einfach Resources erstellen. Dieser grafische 
Resource-Editor ermöglicht die Erstellung von Resources, auf die 
das Programm später zugreift, auf sehr intuitive Weise. Mit die- 
sem Programm können neue Resource-Dateien angelegt oder 
bestehende Resource-Dateien verändert werden. Möchte man (wie 
dies ja gefordert wird) sämtliche String-Konstanten aus dem 
Quelltext verbannen, so legt man mit Hilfe von ResEdit die ent- 
sprechenden String('STR ')-Resources in der fertig übersetzten 
Applikation an. Das Programm kann dann mit Hilfe von Resource- 
Manager-Routinen wie Get1Resource auf diese String-Resources 
zugreifen und den Text darstellen. Auch kompliziertere Resources 
lassen sich mit Hilfe von ResEdit erstellen. Die folgende Grafik 


illustriert die Modifikation bzw. die Erstellung einer Dialog- 
Beschreibungs-Resource. Diese Resource enthält das Layout ei- 
ner Dialog-Box, die Positionen und Größen der Buttons, ihreNamen 
oder auch die Definition einer Check-Box. Die Erstellung der so- 
genannten "Dialog Items" (Buttons, Check-Boxes etc.) ist in die- 
sem Programm so einfach wie das Zeichnen einer Grafik in einem 
Grafikprogramm. Es ist kein Programmieraufwand nötig, um eine 
Resource mit Hilfe von ResEdit zu erstellen oder zu verändern. 
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8.4.2 Rez 

Rez ist ein MPW-Shell-Tool, welches eine Resource-Description- 
Datei in eine Resource-Datei übersetzt. Apple hat zu diesem Zweck 
eine eigene, kleine Programmiersprache erfunden, die sogenannte 
"Resource Description Language". Eine Resource-Description-Datei 
ist eine Textdatei, die Befehle aus der Resource-Description- 
Language enthält. Mit Hilfe dieser Befehle können Resources 
beschrieben werden, die in einem Programm benötigt werden. 
Um bei dem vorangegangenen Beispiel der Definition einer String- 
Resource zu bleiben: Man würde eine Rez-Datei erstellen, die 
die Befehle für die benötigten String-Resources enthält. Diese Rez- 





Abb. 8-1 

Resedit stellt die 
Resource-Typen und 
Resources grafisch dar. 
Mit diesem 
Programmierer- 
werkzeug können fast 
alle Oberflächen- 
elemente eines 
Macintosh-Programms 
interaktiv erstellt 
werden. 


Das Rez-Tool ist ein 
Resource-Compiler. Es 
übersetzt eine 
Resource-Description- 
Datei (Rez-Datei) in eine 
Resource-Datei. 
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Die Resource- 
Description-Language 
ist von der Program- 
miersprache ’C" 
abgeleitet. Sie dient der 
textuellen Beschreibung 
von Resources. 


Rez-Dateien können 
(wie andere Quelltext- 
dateien) in den Make- 

Prozeß eingebunden 

werden. 





Datei wird dann in den Make-Prozeß mit eingebunden, so daß 
die Rez-Datei automatisch mit Hilfe des Resource-Compilers Rez 
übersetzt wird. 

Im folgenden Beispiel einer Rez-Datei werden zwei String- 
Resources erzeugt. Die erste String-Resource bekommt die 
Resource-ID 128 und enthält den Text "Eine String-Resource". 
Die zweite String-Resource (ID 129) enthält den Text "Die 2. String 
Resource". 


#include "Types.r" /* Typendeklarationen */ 

resource 'STR ' (128) { /* ResType, ResID */ 
"Eine String-Resource" /* Text */ 

}3 

resource 'STR ' (129) { /* ResType, ResID */ 
"Die 2. String-Resource" /* Text */ 


} 


Der Vorteil dieser Methode gegenüber der intuitiveren Methode 
mit ResEdit liegt darin, daß mit Hilfe von Make-Dateien die 
Möglichkeit besteht, sogenannte "Dependencies" aufzubauen. 
Dependencies sind Abhängigkeiten zwischen Quelltext und Object- 
Code. Wenn ein Quelltext verändert wurde, wird dieser Quelltext 
beim nächsten Übersetzen der Gesamt-Applikation automatisch 
neu compiliert. Dieser auch von anderen Entwicklungsumge- 
bungen bekannte Make-Prozeß garantiert die richtige Überset- 
zung sämtlicher Quelltexte. Auch Resource-Description-Datei- 
en können in diesen Make-Prozeß mit eingebunden werden - sie 
werden so automatisch übersetzt, wenn dies nötig ist. 

Ein weiterer Vorteil einer Rez-Datei liegt darin, daß man Kom- 
mentare zu den Resources schreiben kann. So kann man z.B. neben 
der Definition einer 'STR '-Resource den Kommentar schreiben, 
an welcher Stelle des Programms diese Resource benötigt wird. 
Resource-Description-Dateien sind eben ganz normale Textdateien, 
die erst von Rez zu richtigen Resources gemacht werden. 


8.4.3 ResEdit, DeRez und Rez in Kombination 


Die Erstellung von Resources mit Hilfe von Rez hat (wie Sie 
wahrscheinlich schon vermutet haben) einen entscheidenden 
Nachteil: Man muß sich neben der Erlernung der Macintosh- 
Programmierung auch noch mit einer neuen Programmierspra- 
che beschäftigen - Der Resource-Description-Language ! 
Damit einem dieses Übel erspart bleibt, man aber trotzdem die 
Vorteile der Resource-Description-Dateien nutzen kann, gibt es 
ein weiteres Tool, namens DeRez. DeRez ist ein Resource- 
Decompiler, das Gegenstück zu Rez. Mit Hilfe von DeRez kann 
man eine fertige Resource-Datei (die man z.B. mit ResEdit er- 
stellt hat) zu einer Resource-Description-Datei decompilieren. 
DeRez erzeugt dabei genau die Befehle, die der Resource-Compiler 
beim Übersetzen einer Resource-Description-Datei erwartet. 


Shell Editor 


r 
Resource 
descrip- 
tionfiles 
=r 
'TEXT' 

4 ' 


DeRez io . ResEdit 


Die einfache Erstellung einer Resource-Description-Datei sieht 
also so aus: Mit Hilfe von ResEdit wird eine neue Resource-Datei 
angelegt. Die benötigten Resources werden mit Hilfe dieses sehr 
intuitiv zu bedienenden Programms in der angelegten Datei 
erzeugt. Anschließend wird die Resource-Datei mit Hilfe von 
DeRez in eine Resource-Description-Datei (eine Textdatei) 
übersetzt. Diese Datei kann jetzt in den Make-Prozeß mit ein- 
gebunden werden. Auf diese Weise hat man die Möglichkeit, 
Kommentare zu den Resources zu schreiben, ohne die Resources 
textuell beschreiben zu müssen. 


” ä 





Das Tool DeRez ist ein 
Resource-Decompiler. 
Es übersetzt eine 
Resource-Datei in eine 
Resource-Description- 
Datei. 


Abb. 8-2 

Mit Hilfe von ResEdit 
werden die Resources 
grafisch erzeugt. 
Anschließend wird der 
Resource-Compiler 
DeRez verwendet, um 
eine Resource- 
Description-Datei zu 
erzeugen, die dann in 
den Make-Prozeß 
eingebunden wird. In 
diesem Prozeß übersetzt 
der Resource-Compiler 
Rez die Resource- 
Description-Datei in eine 
Resource-Datei, 
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Abb. 8-3 
Quelltextdateien enden 
immer mit".a" (für 
Assembler), '.p" (für 
Pascal) oder mit ‘.c” (für 
C). Der entsprechende 
Compiler übersetzt die 
Quelltextdateien in 
Object-Code-Dateien, 
welche dann vom Linker 
mit den Libraries und 
den Resource-Dateien 
zu einer Applikation 
zusammengebunden 
werden. 


8.5 Compilieren einer Applikation 


Um eine Macintosh-Applikation compilieren zu können, benö- 
tigt man zunächst eine Make-Datei. Diese Make-Datei enthält 
die Informationen, aus welchen Quelldateien die Applikation 
zusammengebaut werden soll. Das Übersetzen der Applikation 
erfolgt dann, indem man das Tool "Make" aufruft, welches die 
benötigten Compiler aufruft und den Linker zum Binden der 
Applikation veranlaßt. 


Shell Editor 








: | 
Object hear 
files As 
=0 'OBJ' 





Resource 
files 











Zum Glück muß man sich am Anfang noch nicht mit der (recht 
komplizierten) Struktur einer Make-Datei auseinandersetzen. 
Apple bietet für den einfachen Einstieg in die MPW-Shell fertige 
Scripts, die das Erzeugen einer Make-Datei automatisieren bzw. 
intuitiver gestalten. Die folgenden Schritte beschreiben den Pro- 
zeß, der nötig ist, um eine Applikation zu übersetzen: 


1. Mit Hilfe des "Set Directory"-Menüpunktes aus dem "Directory"- 
Menü bzw. dem folgenden Dialog den Ordner auswählen, in 
welchem sich die Quelltexte befinden. 

2. Aus dem "Build"-Menü den Menüpunkt "Create Build 
Commands..." auswählen. 

3. Auf den "Sourcefiles..."-Button klicken. 

4. Die Source-Textdateien auswählen und durch Klicken auf den 
"Add"- Button in die Liste der Source-Dateien übernehmen. 

5. Beenden des Dialoges mit "Done". 

6. Eingeben eines Programmnamens in dem Edit-Feld "Program 
Name". 

7. Klicken auf den "Create Make"-Button. 

Jetzt wird automatisch eine der gefürchteten Make-Dateien er- 
stellt. Diese Make-Datei enthält nun die Anweisungen, um die 
Applikation zu übersetzen. Sie kann immer wieder verwendet 
werden, um das Programm zu übersetzen. Beim nächsten Über- 
setzen des Programms brauchen die beschriebenen Schritte nicht 
mehr wiederholt werden. 

8. Auswählen des Menüpunktes "Build" aus dem "Build"- Menü. 
9. Bestätigen des Dialoges mit "OK". 


Nun wird das Programm automatisch übersetzt. Die Ausgaben 
der Compiler bzw. die Statusinformationen des Übersetzungs- 
prozesses werden in das Worksheet (die Console) ausgegeben. 
Nach Beendigung des Übersetzungsprozesses sieht das Worksheet 
etwa so aus: 


# 11:12:20 Uhr ----- Build of Minimum. 
# 11:12:20 Uhr ----- Analyzing dependencies. 
# 11:12:21 Uhr ----- Executing build commands. 


Rez Minimum.r -append -o Minimum 

C -r Minimum.c 

Link -t APPL -c 
# 11:12:32 Uhr ----- Done. 
Minimum 


'7????" Minimum.c.Oo .. 


Zunächst wurde in diesem Beispiel der Resource-Compiler Rez 
gestartet, um die Resource-Description-Datei "Minimum.r" zu 
übersetzen. Danach wurde der C-Compiler aufgerufen und hat 
die Quelltextdatei "Minimum.c" übersetzt. Der anschließende 


nn 8.5 Compilieren einer 





‚Applikation 


Das "Rezept" zum 
Erstellen einer Make- 
Datei bzw. zum 
Übersetzen einer 
Applikation. 


Die MPW-Shell gibt 
während des Compilie- 
rens Statusmeldungen 
über die ausgeführten 
Schritte in das 
Worksheet aus. 
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Linker-Aufruf bindet die erzeugten Dateien in einer Applikation 
zusammen. 

Soll das Programm gestartet werden, so kann dies ganz normal 
vom Finder aus geschehen oder einfach durch Drücken der "Enter- 
Taste" (ganz rechts unten auf der Tastatur). 
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Dieses Kapitel erklärt die Erzeugung und Verwaltung von Fen- 
stern in einem Macintosh-Programm. Es bildet damit dieGrundlage 
für nahezu jedes Programm. Zunächst werden die Besonderhei- 
ten des Macintosh-Window-Managements etwas genauer be- 
leuchtet. Die Datenstrukturen und Routinen des Window-Ma- 
nagers werden dann im weiteren Verlauf des Kapitels erläutert. 
Zum Schluß wird das erste kleine Macintosh-Programm "MINI- 
MUM" vorgestellt. Dieses Programm kann ein Fenster öffnen, es 
ist sozusagen das "Hello World" des Macintosh. Minimum führt 
dabei die bisher vorgestellten Erkenntnisse zu einem Teil zu- 
sammen. Das Programm benutzt den Window-Manager, um ein 
Fenster zu erzeugen und verwendet dabei indirekt den Resource- 
bzw. Memory-Manager. Dieses minimale Programm stellt eine 
Experimentierplattform dar, die zum Erkunden von QuickDraw 
und anderen Managern verwendet werden kann. Minimum bil- 
det auch die Grundlage für die Erstellung komplexerer Applika- 
tionen im Verlauf der nächsten Kapitel. 


9.1 Der Window-Manageı 


Der Window-Manager beschäftigt sich (wie der Name schon sagt) 
mit der Generierung und Verwaltung von Fenstern. Auf dem 
Macintosh gibt es viele verschiedene Arten von Fenstern; die 
verschiedenen Standard-Window-Typen sind in Abb. 9-1 darge- 
stellt. 
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Abb. 9-1 

Die Fenstertypen und 
die assoziierten 
Konstanten. Diese 
Konstanten werden bei 
der Definition des 
Fensters verwendet, um 
den Fenstertyp zu 
spezifizieren. 


Um ein Fenster zu 
beschreiben, werden 
'WIND'-Rescoures 
verwendet, die u.a. 
Informationen über die 
Position, Größe und den 
Fenstertyp enthalten. 


u 


A 
4 


documentProc noGrowDocProc rDocProc 
plainDBox altDBoxProc dBoxProc 


Der Window-Manager setzt auf dem Memory-Manager, Quick- 
Draw und dem Resource-Manager auf. Er benutzt beispielswei- 
se den Resource-Manager dazu, um bei der Erzeugung eines 
Fensters eine Fenster-Beschreibungs-Resource zu laden. Eine solche 
'WIND'-Resource enthält die initiale Größe und Position eines 
Fensters, den Fenster-Typ und den Fenstertitel. Möchte man ein 
Fenster erzeugen, so übergibt man der entsprechenden Funk- 
tion die Resource-ID einer 'WIND'-Resource, die sich im Resource- 
Fork der Applikation befindet. Die Funktion lädt diese Window- 
Beschreibungs-Resource mittels des Resource-Managers und 
generiert anhand der in diesem Window-Template enthaltenen 
Informationen das Fenster. 

Das Zeichnen eines Fensters wird mit Hilfe von QuickDraw- 
Routinen erledigt, die Verwaltung der Überlappungen von Fen- 
stern wird mit Hilfe von Regions implementiert. Der Window- 
Manager benutzt Regions dazu, ein Programm daran zu hindern, 
über die Grenzen eines Fensters hinaus zu zeichnen. Wir brau- 
chen uns als Programmierer (zum Glück) nicht darum zu küm- 
mern, ob das Fenster, in das wir hineinzeichnen wollen, von ei- 
nem anderen überlappt wird. Jedes Fenster hat eine Region, die 
den sichtbaren Bereich eines Fensters beschreibt, die sogenannte 
"Visible Region" (visRgn). QuickDraw beachtet die Grenzen dieser 
Visible-Region genauso, wie dies mit der Clipping-Region ge- 
schieht. Zeichenoperationen werden auf die Grenzen dieser Region 
beschränkt. 





9.2 Routinen und 


. Datenstrukturen 





9.2 Routinen und Datenstrukturen 


Nun zum Kern des Window-Managers, den Routinen und Da- 
tenstrukturen, die zur Generierung und Verwaltung eines Fen- 
sters zur Verfügung stehen: 

Jedes Fenster besitzt einen WindowRecord, diese Datenstruktur 
bildet die Basis des Fensters. Dieser WindowRecord enthält In- 
formationen über das Fenster selbst, in ihm sind beispielsweise 
Informationen über den Typ oder auch die Position des Fensters 
enthalten. Viele Window-Manager-Routinen verlangen zur Be- 
arbeitung eines Fensters die Adresse des zugehörigen Window- 
Records. Über diesen WindowRecord wissen die Funktionen dann, 
mit welchem Fenster sie arbeiten sollen. 

In der Regel greift man selten direkt auf die Felder dieser Daten- 
struktur zu. Um die Gesamtfunktionalität des Window-Mana- 
gers zu erklären, wird diese Struktur hier trotzdem vorgestellt. 
Ein Window-Record ist wie folgt deklariert: 





l: struct WindowRecord { Der WindowRecord 
2 GrafPort port; bildet die Basis eines 
3: short windowKind; Fensters. Er enthält (als 
4: Boolean visible; erstes Feld) einen 
5: Boolean hilited; ö 
6 Boolean goAwayFlag; GrafPort; jedes Fenster 
7 Boolean spareFlag; enthält seine eigene 
8: RgnHandle strucRgn; Zeichenumgebung 
9: RgnHandle contRgn; (Koordinatensystem- 
10: RgnHandle updateRgn; ursprung, Clipping- 
11: Handle windowDefProc; Region ete.). 
12: Handle dataHandle; 
13: StringHandle titleHandle; 
14: short titleWwidth; 
15; ControlHandle controlList; 
16: struct WindowRecord *nextWindow; 
1:72 PicHandle windowPic; 
18: long refCon; 
19%); 


Das erste Feld des WindowRecords (port) entspricht dem mit 
diesem Fenster assoziierten QuickDraw-GrafPort. Man muß sich 
anstelle dieses Feldes einen kompletten GrafPort mit all seinen 
Feldern vorstellen. Jedes Window hat also seine eigene, kom- 
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Abb. 9-2 

Die verschiedenen 
Regions, die für die 
Verwaltung eines 
Fensters verwendet 
werden. 


plette Zeichenumgebung. Dies vereinfacht das Arbeiten mit 
mehreren Fenstern enorm. Wir brauchen uns beim Umschalten 
zwischen zwei Fenstern die QuickDraw-Attribute nicht zu mer- 
ken, das aktive Fenster bestimmt die aktuelle Zeichenumgebung 
und damit auch sämtliche QuickDraw-Zeichen-Attribute wie die 
PenSize, den aktuellen Font oder die Clipping-Region. 


Ein Macintosh-Fenster ist eine Art virtueller Bildschirm, da es seine 
eigene Zeichenumgebung (GrafPort) besitzt. 


Das Feld windowKind enthält die Identifikationsnummer des 
Window-Typs, beispielsweise documentProc. Dieses Feld ist für 
uns recht uninteressant, da der Typ des Fensters über Resources 
definiert wird. 

An dem Boolean visible kann man erkennen, ob ein Fenster 
sichtbar ist, oder sozusagen im RAM schlummert. 

Ist das Fenster aktiv (es hat horizontale Streifen in der Titel-Leiste), 
so ist das Feld hilited auf true gesetzt. 

Hat das Fenster ein Schließ-Feld (Go-Away-Box), so ist der Boolean 
goAwayFlag true. 

Das Feld spareFlag ist für zukünftige Erweiterungen des Window- 
Managers reserviert. 

Die nachfolgenden drei Regions werden zur Verwaltung der 
Fensterform verwendet. Die Region strucRgn beschreibt den 
Bereich, der dem kompletten Fenster entspricht. Dieses Feld ent- 
spricht der Summe von contRgn und der dragRgn (die nicht im 
WindowRecord verwaltet wird). 


goAwayRgn dragRgn zoomRen 


WE Z PTR 


De u DT 





contRgn 
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Das Feld contRgn beschreibt den Bereich, der dem Fensterinhalt 
entspricht. Dies ist der maximale Bereich, in dem ein Macintosh- 
Programm mit Hilfe von QuickDraw zeichnen kann. 

Das Feld visRgn eines GrafPorts enthält die Region, die den ge- 
rade sichtbaren Bereich des Fensters beschreibt. Ist das Fenster 
im Vordergrund, so entspricht diese Region der strucRgn (dem 
gesamten Fenster), wird es jedoch von anderen Fenstern überlappt, 
so beschreibt visRgn genau den sichtbaren Bereich des Fensters. 


Euweg® T Abb. 9-3 
Die Visible-Region 
| (visRgn) eines Fensters 
! _ _ (bzw. eines GrafPorts) 
j beschreibt den sichtba- 

ren Bereich des 

Ä Fensters. Diese Region 
verhindert, daß über die 
Grenzen des Fensters 

visRgn hinaus gezeichnet wird. 

QuickDraw achtet beim Zeichnen darauf, daß Zeichenoperationen 

nicht die gemeinsame Fläche von visRgn und contRgn verlas- 

sen. Auf diese Weise kann ein Mac-Programm nie "versehent- 

lich" über die Grenzen seines Fensters hinaus zeichnen, noch ein 

über dem Ziel-Fenster liegendes Fenster übermalen. Da QuickDraw 

auch auf die beschriebene Clipping-Region eines GrafPorts achtet, 

ergibt sich der Zeichenbereich aus der gemeinsamen Fläche von 

visRgn, contRgn und der clipRgn des GrafPorts (siehe Abb. 9-3). 


Zeichenbereich= Gemeinsamer Bereich von visRgn, contRgn und clipRgn. 


Das Feld updateRgn gibt mir eine willkommene Gelegenheit, die 
Einzelteile des Wissens, das Sie sich über Events, QuickDraw 
und den Window-Manager erworben haben, zusammenzufügen. 
Wird ein Fenster, welches ein anderes überlappt, verschoben, so 
daß Teile des im Hintergrund liegenden Fensters wieder sichtbar 
werden, so ist das Programm dafür zuständig, den Inhalt der 
freigelegten Bereiche neu zu zeichnen; das Programm muß die 
Grafik, die an dieser Stelle liegt, neu zeichnen. Der Window-Ma- 
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Die Region updateRgn 
beschreibt den Bereich 
eines Fensters, der neu 
gezeichnet werden muß. 





Abb. 9-4 

Um ein Floating- 
Window zu erzeugen, 
muß eine eigene 
Window-Definition- 
Function (WDEF) 
verwendet werden. 


nager akkumuliert alle freigelegten Bereiche in die updateRgn 
des WindowRecords und informiert das Programm mittels ei- 
nes Update-Events von der Notwendigkeit des Neuzeichnens. 
Das Programm reagiert dann auf diesen Update-Event, indem 
es die Clipping-Region auf die updateRgn des WindowRecords 
setzt und die gesamte Grafik neuzeichnet. So werden nur die 
Teile der Grafik gezeichnet, die auch wirklich neu gezeichnet 
werden müssen. Dieses Verfahren spart eine Menge Rechenzeit, 
denn nur die QuickDraw-Zeichenoperationen, die innerhalb der 
Clipping-Region liegen, werden ausgeführt. 


Bis jetzt wurde immer davon gesprochen, daß der Window-Ma- 
nager das Fenster zeichnet. Dies ist eigentlich nicht ganz richtig. 
In Wirklichkeit ist ein bestimmter Typ von vordefinierten Funk- 
tionen (die sogenannten "Window Definition Functions" (WDEF)) 
für das Zeichnen des Fensters verantwortlich. Der Window-Ma- 
nager übernimmt die Verwaltung, die WDEF das Zeichnen des 
Fensters (Titelleiste, Titel, Umrandung etc.). Solche WDEFSs sind 
als eigenständige Object-Code-Resources im System enthalten. 
Das Feld windowDefProc eines WindowRecords enthält einen 
Handle auf die geladene WDEF-Resource, die Window-Definiti- 
on-Function. Es existieren mehrere vordefinierte WDEFSs, einige 
Programme benutzen jedoch auch die Möglichkeit des Window- 
Managers, eine eigene WDEF zu haben, also selbst für das Zeichnen 
des Fensters verantwortlich zu sein. Dies ist natürlich nur dann 
interessant, wenn man mit dem Aussehen und der Funktionali- 
tät der normalen, Standard-WDEFSs nicht zufrieden ist. Benutzt 
werden diese Custom-WDEFSs für die sogenannten "Floating 
Windows", die meistens eine Werkzeugleiste zum Zeichnen ent- 
halten und eine verkleinerte Titelleiste haben. 

Diese Art von Fenstern nennt man Floating-Windows, weil man 
sie nicht in den Hintergrund klicken kann. Sie "schweben" sozu- 
sagen immer über allen anderen Fenstern. 


Das Feld dataHandle wird von den WDEFS dazu verwendet, um 
eigene Daten abzulegen. 

Der StringHandle titleHandle ist ein Handle auf einen Pascal- 
String, der in der Titelleiste des Fensters erscheint. 
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Das Feld titleWidth gibt die Breite des Strings in Pixeln (Bild- Ve ee ee ER NIen JE SRENEREN TEE EHRE 
schirmpunkten) an. Normalerweise sind diese Felder für Pro- 

grammierer recht uninteressant. 

Fenster haben bekanntlich öfter mal einen Scrollbar (Roll-Bal- 

ken) oder auch schon mal einen Button. Diese Strukturen nennt 

man Controls. Enthält ein Fenster Controls, so zeigt das Feld 

controlList auf den Anfang einer verketteten Liste der zu die- 

sem Fenster gehörenden Controls. Controls und ihre Verwaltung 

werden in Kapitel 12 beschrieben. 

Der Window-Manager reflektiert die Ordnung der Fenster (welches 

über welchem liegt) durch Verkettung der WindowRecords. Je- 

des Fenster verweist in dem Feld nextWindow seines Window- 

Records auf das Fenster, welches in der Hierarchie als nächstes 

folgt. Diese Verkettung geht vom obersten bis zum untersten 

Fenster, quer über alle laufenden Applikationen hinweg. 

Oft möchte man dem Benutzer ein Fenster zeigen, das einen 

statischen Inhalt hat. Ein Beispiel dafür wäre eine Legende bei 

einem Statistikprogramm, die sich in einem separaten Fenster 

befindet. Um die Implementierung eines statischen Fensterinhaltes 

zu erleichtern, gibt es das Feld windowPic. Hier kann man einen 

PicHandle einsetzen, der auf ein Picture zeigt, welches den In- 

halt des statischen Fensters zeichnet. Der Window-Manager 

übernimmt dann automatisch alle Update-Events für dieses 

Fenster. Wir brauchen uns überhaupt nicht mehr um das Zeich- 

nen des Fensterinhaltes zu kümmern. Dieses Feature ist zwar 

kein Meilenstein in der Entwicklung der Fenstertechnologie, kann 

jedoch in manchen Fällen recht nützlich sein. 

Das letzte Feld (refCon) ist ein long, der uns als Programmierern Das Feld refCon eines 
zur Verfügung steht. Dieses Feld kann nach Belieben gesetzt WindowRecords wird 
werden. Es wird von vielen Programmen dazu verwendet, die von vielen Programmen 
Daten, die in einem Fenster dargestellt werden, zu verwalten. In verwendet, um einen 
diesem Feld wird meist ein Handle auf einen Daten-Record oder Handle auf die Daten 
auf weiter verzweigende Strukturen abgelegt. So erreicht man abzulegen, welche in 
eine Verbindung zwischen den Fenstern und den Daten, diein dem Fenster dargestellt 
ihnen dargestellt werden. Soll bei einem Update-Event bei- werden. Auf diese Weise 
spielsweise neu gezeichnet werden, so genügtes, eine universell entsteht eine eindeutige 
gehaltene Zeichenroutine nur noch auf das entsprechende Fen- Beziehung zwischen 
ster anzusetzen. Diese Zeichenroutine kann dann den imrefCon Fenster und Daten. 
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GetNewWindow 


Wenn für den Parameter 
wStorage der Wert 
NULL übergeben wird, 
legt GetNewWindow 
einen nonrelocatable- 
Block für die Verwaltung 
des Fensters an. 





enthaltenen Handle verwenden, um an die zu zeichnenden Da- 
ten heranzukommen. 


Die Funktion InitWindows initialisiert den Window-Manager. 
Diese Funktion muß aufgerufen werden, bevor eine der im 
Nachfolgenden beschriebenen Routinen verwendet wird. Üb- 
licherweise wird diese Routine zu Beginn des Programms (in der 
Initialisierungs-Routine) aufgerufen. 


pascal void InitWindows (void); 


Um ein neues, leeres Fenster zu erzeugen, wird die Funktion 
GetNewWindow aufgerufen. 


pascal WindowPtr GetNewWindow ( 
short windowID, 
void *wStorage, 
WindowPtr behind); 


Diese Funktion verlangt als ersten Parameter (windowID) die 
Resource-ID einer 'WIND'-Resource (eines Window-Templates). 
Diese 'WIND'-Resource muß im Resource-Fork der Applikation 
enthalten sein. In ihr werden Größe, Position und Art des Fen- 
sters beschrieben. Anstelle des Parameters wStorage kann man 
die Adresse eines WindowRecords übergeben. Dieses Feature 
wird nur dann benötigt, wenn man zur Laufzeit der Applikation 
ständig neue Fenster erzeugen möchte. Gehen wir zunächst einmal 
davon aus, daß in unserer Applikation nur ein Fenster zur Ver- 
fügung steht, so kann man anstelle von wStorage NULL über- 
geben. GetNewWindow alloziiert in diesem Fall einen Pointer 
(einen nonrelocatable-Block) im Speicherbereich unserer Appli- 
kation. Dieser Block wird dann vom Window-Manager zur Ver- 
waltung des Windows bzw. zum Abspeichern der Window-Daten 
benutzt. 

Normalerweise erzeugt GetNewWindow das neue Fenster über 
allen anderen bereits bestehenden Fenstern. Der letzte Parameter 
(behind) kann jedoch auch ein Pointer auf ein bereits bestehen- 
des Window sein. In diesem Fall wird das neue Fenster hinter 
dem Fenster angelegt, auf das behind zeigt. Dieses Feature wird 
selten benötigt. Möchte man das neue Fenster über allen ande- 
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ren Fenstern erzeugen, so kann man anstelle des Parameters behind 
den Wert -1 übergeben. 

Als Ergebniswert gibt GetNewWindow die Adresse des neu an- 
gelegten nonrelocatable-Blocks zurück. Dies ist die Adresse ei- 
nes WindowRecords und wird von allen anderen Window-Ma- 
nager-Routinen als Eingabeparameter verlangt. Mit Hilfe dieses 
WindowPtrs spezifizieren wir, mit welchem Fenster die Routinen 
arbeiten sollen. 


Nun soll es auch schon einmal vorgekommen sein, daß der Be- CloseWindow 
nutzer ein Fenster schließen möchte (Benutzer klickt in die Close- 
Box des Fensters). Wir reagieren auf dieses Verlangen, indem 
wir die Funktion CloseWindow oder DisposeWindow aufrufen. 


pascal void CloseWindow (WindowPtr theWindow); 


CloseWindow läßt das durch theWindow verwaltete Fenster vom 
Bildschirm verschwinden und gibt den von dem Fenster belegten 
Speicherplatz frei. Diese Funktion gibt sämtliche Datenstruktu- 
ren frei, die im WindowRecord enthalten sind (z.B. die Regions). 
Der WindowRecord selbst wird jedoch nicht freigegeben, da 
dieser Record eventuell gar kein Memory-Manager-Block ist, 
sondern auch z.B. eine globale Variable des Programms sein kann. 
Ist bei der Erzeugung des Fensters (Aufruf von GetNewWindow) 
ein nonrelocatable-Block angelegt worden (wStorage = NULL), 
so sollte anstelle von CloseWindow die Funktion DisposeWindow 
aufgerufen werden, um auch den WindowRecord selbst freizu- 
geben. 


pascal void DisposeWindow (WindowPtr theWindow) ; DisposeWindow 


DisposeWindow ruft CloseWindow auf und gibt zusätzlich noch 
den Speicherplatz frei, der von dem WindowRecord des Fensters 
belegt wird. Diese Funktion darf nur dann aufgerufen werden, 
wenn bei der Erzeugung des Fensters eine neuer nonrelocatable- 
Block angelegt worden ist. 
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Soll ein Fenster zwar vom Bildschirm verschwinden, die Daten- 
strukturen (Windowkecord etc...) aber erhalten bleiben, so kann 
die Funktion HideWindow verwendet werden. 


pascal void HideWindow (WindowPtr theWindow); 


HideWindow "versteckt" das Fenster, welches durch den Para- 
meter theWindow spezifiziert wird. Das Fenster kann anschlie- 
ßend durch einen Aufruf der Funktion ShowWindow wieder 
sichtbar gemacht werden. 


pascal void ShowWindow (WindowPtr theWindow); 


ShowWindow geht davon aus, daß das Fenster, auf welches 
theWindow zeigt, bereits existiert. ShowWindow erzeugt also 
kein neues Fenster, sondern sorgt lediglich dafür, daß ein un- 
sichtbares Fenster wieder sichtbar wird. 


Wenn der Benutzer auf ein im Hintergrund liegendes Fenster 
klickt, sollte das Programm die Funktion SelectWindow aufrufen. 


pascal void SelectWindow (WindowPtr theWindow); 


Diese Funktion holt das Fenster, auf welches der Parameter 
theWindow zeigt, nach vorn und aktiviert es. Aktivieren bedeutet, 
daß die Streifen in der DragRegion gezeichnet werden, und ein 
Activate-Event für dieses Fenster erzeugt wird. Das Fenster, 
welches bisher im Vordergrund lag, wird als inaktiv gekenn- 
zeichnet und bekommt einen DeActivate-Event. 


Um den Titel eines Fensters zur Laufzeit zu ändern, steht die 
Funktion SetWTitle zur Verfügung. Diese Funktion wird bei- 
spielsweise verwendet, um einem neuen Fenster nach dem Öff- 
nen eines Dokuments den Namen der gelesenen Datei zu geben. 


pascal void SetWTitle ( WindowPtr theWindow, 
Str255 *title); 
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SetWTitle ändert den Titel des Fensters, auf welches theWindow 
zeigt. Der neue Titel des Fensters wird durch den String, auf den 
title zeigt, spezifiziert. 


Die Funktion GetWTitle wird verwendet, um auf den Fenster- GetWTitle 
titel zuzugreifen. 


pascal void GetWTitle ( WindowPtr theWindow, 
Str255 *title); 


GetWTitle gibt den Fenstertitel des Fensters, auf welches der 
Parameter theWindow zeigt, in dem String title an das Pro- 
gramm zurück. 


Wenn das Programm mehrere Fenster verwalten soll, so wird FrontWindow 
die Funktion FrontWindow verwendet, um eine Referenz auf das 

vorderste Fenster zu erhalten. Diese Funktion wird von Pro- 

grammteilen verwendet, welche sich bei ihrer Ausführung stets 

auf das vorderste Fenster beziehen. 


windowPtr FrontWindow (void); 


FrontWindow gibt die Adresse des vordersten Fensters als 
Ergebniswert an das Programm zurück. 


Wenn ein Macintosh-Programm feststellt, daß durch bestimmte _InvalRect 
Berechnungen oder Aktionen ein bestimmter Bereich eines Fensters 

neu gezeichnet werden muß, so kann es durch einen Aufruf der 

Funktion InvalRect bewirken, daß dieser Bereich neugezeichnet 

wird. 


pascal void InvalRect (const Rect *badRect); 


InvalRect akkumuliert das übergebene Rechteck (badRect) in die 
updateRgn des WindowRecords und schickt dem Programm einen 
Update-Event für das Fenster. Das Programm reagiert dann auf 
diesen Event, indem es die neuzuzeichnenden Bereiche restau- 
riert. Der Aufruf dieser Funktion ist einem direkten Neuzeichnen 
der Grafik vorzuziehen, da dieser Mechanismus über die stan- 
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dardisierten Event-Behandlungsroutinen des Programms läuft, 
und so garantiert korrekt abgearbeitet wird. 


pascal void InvalRgn (RgnHandle badRgn); 


InvalRgn funktioniert genau wie InvalRect, akkumuliert jedoch 
die Fläche der übergebenen Region in die Update-Region 
(updateRgn) des WindowRecords. 


Wenn ein Macintosh-Programm einen Update-Event für ein Fenster 
bekommt, so ruft es zunächst die Funktion BeginUpdate auf und 
zeichnet dann den gesamten Fensterinhalt neu. 


pascal void BeginUpdate (WindowPtr theWindow); 


Diese Funktion schränkt die Visible-Region (visRgn) des Fensters 
auf den neuzuzeichenden Bereich (updateRgn des Window- 
Records) ein. Da die Visible-Region des Fensters (wie beschrie- 
ben) den Zeichenbereich einschränkt, kann das Programm die 
gesamte Grafik zeichnen, ohne auf die Update-Region achten zu 
müssen. Nur die Teile der Grafik eines Fensters werden neu ge- 
zeichnet, die innerhalb des neuzuzeichnenden Bereiches liegen. 
Diese Technik beschleunigt den Fensteraufbau und trägt zu ei- 
nem "ruhigeren" Bildschirmaufbau bei. 


Nachdem die Funktion BeginUpdate aufgerufen und der Inhalt 
des Fensters neugezeichnet worden ist, wird die Funktion 
EndUpdate aufgerufen. Diese Funktion setzt die Visible-Region 
des Fensters auf den ursprünglichen Bereich zurück. Mit dem 
Aufruf dieser Funktion ist die Update-Event-Behandlung abge- 
schlossen. 


pascal void EndUpdate (WindowPtr theWindow) ; 


Findet ein MouseDown-Event statt, so muß das Programm zu- 
nächst einmal herausfinden, in welchem Bereich des Bildschirms 
der Mausklick liegt. Dies kann anhand der Mausklick-Koordi- 
naten bzw. mit Hilfe der Funktion FindWindow geschehen. 


pascal short FindWindow ( Point thePoint, 
WindowPtr *theWindow) ; 


Dieser Funktion übergibt man mit dem Parameter thePoint die 
Koordinaten des Mausklicks. FindWindow sucht dann den Bereich, 
in dem sich der Mausklick befindet. Befindet sich der Mausklick 
in einem Fenster, so gibt FindWindow in der Variable, auf die 
theWindow zeigt, den WindowPtr des "getroffenen" Fensters 
zurück. Der Ergebniswert der Funktion spezifiziert dabei genauer, 
in welchem Bereich des Fensters der Mausklick lag. 
FindWindow erkennt nicht nur Mausklicks, die in einem Fenster 
liegen, sondern analysiert den gesamten Bildschirm. Hat der 
Benutzer beispielsweise in die Menüleiste geklickt, so gibt 
FindWindow den entsprechenden Wert als Ergebniswert zurück. 
Der Parameter theWindow ist dann ungültig. 

Der Ergebniswert von FindWindow kann mit den folgenden 
vordefinierten Konstanten verglichen werden: 


#define inMenuBar 1 


Der Mausklick liegt in der Menüleiste. In diesem Fall muß mit 
dem Menu-Manager zusammengearbeitet werden, um das Her- 
unterklappen des Menüs bzw. die Auswahl eines Menüpunktes 
zu ermöglichen. 


#define inSysWindow 2 


Diese Konstante gibt an, daß der Mausklick im Fenster eines DAs 
liegt. Diese Meldung braucht nur behandelt zu werden, wenn 
das Programm unter System 6 und dem normalen Finder (Single- 
Tasking-Umgebung) laufen soll. In diesem Fall muß der Mausklick 
an das DeskAccessory (Schreibtischprogramm) weitergeleitet 
werden, indem die Desk-Manager-Funktion SystemClick aufge- 
rufen wird. Diese Funktion übernimmt dann die notwendigen 
Aktionen, indem sie mit den Schreibtischprogrammen kommu- 
niziert. 


#define inContent 3 
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Der Benutzer hat in den inneren Bereich des Fensters (contRgn) 
geklickt. In diesem Fall zeigt die Variable, deren Adresse bei 
theWindow übergeben wurde, auf das getroffene Fenster. Das 
Programm muß dann entsprechend reagieren. Je nachdem, ob 
es eine Textverarbeitung oder z.B. ein Grafikprogramm ist, fällt 
die Reaktion des Programms unterschiedlich aus. Bei einer 
Textverarbeitung wird ein Content-Klick normalerweise dazu 
verwendet, um dem Benutzer die Selektion von Text zu ermög- 
lichen, solange er die Maustaste gedrückt hält. Bei einem Grafik- 
programm wird dieser Wert u.a. zum Zeichnen von grafischen 
Objekten verwendet. 


#define inDrag 4 


Der Benutzer möchte ein Fenster verschieben, da erin die dragRgn- 
Region des Fensters geklickt hat. Das Fenster, welches verscho- 
ben werden soll, wird durch die Variable, auf dietheWindow zeigt, 
gekennzeichnet. Das Programm reagiert, indem es die Funktion 
DragWindow aufruft, welche es dem Benutzer erlaubt, das Fenster 
zu verschieben. 


#define inGrow 5 


Der Benutzer hat in die Grow-Region des Fensters geklickt. Dies 
bedeutet, daß er das Fenster vergrößern oder verkleinern möchte. 
Das Programm reagiert dann, indem die Funktion GrowWindow 
aufgerufen wird, die es dem Benutzer ermöglicht, die Fenstergröße 
zu verändern. 


#define inGoAway 6 


Der Benutzer möchte das Fenster schließen. In diesem Fall wird 
(wie bei den vorhergehenden drei Fällen) das entsprechende 
Fenster durch die Variable, auf die theWindow zeigt, spezifi- 
ziert. Das Programm reagiert mit dem Aufruf der (später be- 
schriebenen) Funktion TrackGoAway, und falls diese true zu- 
rückgibt, mit CloseWindow oder DisposeWindow. 


#define inZoomOut 8 


Bei diesem Wert hat der Benutzer in die "Zoom-Box" des Fen- 
sters geklickt. Er möchte, daß das Fenster an die volle 
Bildschirmgröße angepaßt (gezoomt) wird. Das Programm sollte 
zunächst die Funktion TrackBox und dann den Ergebniswert dieser 
Funktion untersuchen. Soll das Fenster gezoomt werden 
(Ergebniswert = true), so wird die Funktion ZoomWindow auf- 
rufen, um diese Aufgabe zu erledigen. 


#define inZoomIn 7 


Auch bei diesem Wert hat der Benutzer in die "Zoom-Box" des 
Fensters geklickt. Der Ergebniswert inZoomIn bedeutet das Ge- 
genteil von inZoomOut. InZoomIn bedeutet, daß der Benutzer 
nach einem inZoomOut zur vorherigen Größe des Fensters 
"zurückzoomen" möchte. Ein Macintosh-Programm reagiert, in- 
dem es zunächst die Funktion TrackBox und anschließend 
ZoomWindow aufruft, die das Fenster auf den letzten Zustand 
zurücksetzt. 
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Im Folgenden werden die dargestellten Window-Manager-Rou- 
tinen erläutert, die zur Verwaltung eines Fensters benötigt werden. 
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Abb. 9-5 

Die Grafik demonstriert 
den "Flow of Control" 
(Funktionsablauf), mit 
dem das Programm auf 
einen MouseDown- 
Event reagiert. 

Anhand des Ergebnis- 
wertes von FindWindow 
entscheidet das 
Programm, welche 
Routinen aufgerufen 
werden. 
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TrackBox 


Abb. 9-6 

Die Abbildung zeigt die 
Funktionalität von 
TrackBox. Liegt die 
Mausposition innerhalb 
der Zoom-Box, so wird 
sie 'gedrückt', ist sie 
außerhalb, so wird sie 
als nicht gedrückt 
gezeichnet. 


ZoomWindow 


Hat der Benutzer in die "Zoom-Box" eines Fensters geklickt 
(FindWindow hat inZoomIn oder inZoomOut zurückgegeben), 
so wird die Funktion TrackBox aufgerufen. TrackBox übernimmt 
die Kontrolle und verfolgt die Mausposition solange, bis der 
Benutzer die Maustaste losgelassen hat. Inder Zwischenzeit wird 
die Close-Box entsprechend der aktuellen Mausposition entwe- 
der "gedrückt" oder nicht gedrückt gezeichnet. 
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pascal Boolean TrackBox ( WindowPtr theWindow, 
Point thePt, 
short partCode); 


Bei einem Aufruf von TrackBox muß das Fenster, welches betroffen 
ist, durch den Parameter theWindow spezifiziert werden. Hier 
übergibt man den von FindWindow zurückgegebenen WindowPtr. 
Der Parameter thePt muß der Startposition des Mausklicks (wie 
sie bei einem MouseDown-Event mitgeliefert wird) entsprechen. 
In dem Parameter partCode übergibt man den von FindWindow 
zurückgegebenen Wert, also inZoomin oder inZoomOut. 

Hat der Benutzer die Maustaste innerhalb der Zoom-Box losge- 
lassen, so gibt TrackBox den Wert true zurück. In diesem Fall 
sollte das Programm die Funktion ZoomWindow aufrufen, um 
auf den Befehl des Benutzers zu reagieren. Gibt die Funktion 
false zurück, so hat der Benutzer die Aktion abgebrochen, indem 
er die Maustaste außerhalb der Zoom-Box losgelassen hat. Das 
Programm sollte dann nichts tun und in die Main-Event-Loop 
zurückkehren. 


Die Funktion ZoomWindow "zoomt" das Fenster von der aktu- 
ellen Größe auf die volle Bildschirmgröße des Hauptbildschirms, 
oder wieder auf die ursprüngliche Größe zurück. Diese Funk- 
tion wird dann aufgerufen, wenn ein MouseDown-Event in der 
Zoom-Box eines Fensters lag und die Funktion TrackBox den Wert 
true zurück gegeben hat. 


windowPtr theWindow, 
short partCode, 
Boolean front); 


pascal void ZoomwWindow ( 


Der Parameter theWindow spezifiziert das Fenster, welches 
"gezoomt" werden soll, theWindow zeigt auf den WindowRe- 
cord des betroffenen Fensters. Anstelle von partCode übergibt man 
den Ergebniswert der Funktion FindWindow, also inZoomIn oder 
inZoomOut. Wenn der Boolean front auf true gesetzt wird, so holt 
ZoomWindow das Fenster nach vorn, wenn es noch nicht vorne 
gewesen ist. Eigentlich ist es egal, was man an dieser Stelle übergibt, 
da ein Fenster, wenn in die Zoom-Box geklickt wird, immer vorne 
sein muß. Der Parameter existiert nur für die Fälle, bei denen 
man diese Funktion nicht in Reaktion auf einen Mausklick in die 
Zoom-Box, sondern z.B. in Reaktion auf eine Menüauswahl auf- 
rufen möchte. Zur "Sicherheit" kann man einfach true überge- 
ben. (Dann wird das Fenster nach vorne geholt, wenn es noch 
nicht vorne war.) 


TrackGoAway macht das für die Close-Box, was TrackBox für 
die Zoom-Box tut. Es übernimmt die Kontrolle und verfolgt die 
Mausposition, solange der Benutzer die Maustaste gedrückt hält. 
Während dieses "Verfolgens" zeichnet TrackGoAway die Go- 
Away-Box entweder in gedrücktem oder in nicht gedrücktem 
Zustand. 
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pascal Boolean TrackGoAway ( 
WindowPtr 
Point 


theWindow, 
thePt); 


Der Parameter theWindow zeigt auf das Fenster, mit dem die 
Aktion durchgeführt werden soll. Hier übergibt man den von 
FindWindow zurückgegebenen WindowPir. Mit thePt spezifi- 
ziert man die Startposition des Mausklicks, wie er in dem 
MouseDown-Event mitgeliefert wurde. 


9.2 Routinen und 





. Datenstrukturen 


TrackGoAway 


Abb. 9-7 

Die Grafik illustriert die 
Funktionalität von 
TrackGoAway. Ist die 
Mausposition innerhalb 
der Glose-Box, dann 
wird diese "gedrückt". Ist 
die Position außerhalb, 
so wird das Schließfeld 
als nicht gedrückt 
gezeichnet. 
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Abb. 9-8 

Wenn der Benutzer ein 
Fenster schließen 
möchte, dessen Daten 
noch nicht gesichert 
worden sind, dann sollte 
das Programm den in 
der Abbildung gezeigten 
Dialog erzeugen. 


GrowWindow 


Die Funktion TrackGoA way liefert den Ergebniswert true, wenn 
der Benutzer die Maustaste innerhalb der Close-Box losgelassen 
hat, also das Fenster schließen möchte. In diesem Fall wird die 
Funktion CloseWindow oder DisposeWindow aufgerufen. Um 
die Macintosh-User-Interface-Guidelines zu beachten, sollte das 
Programm (falls Daten in dem zugehörigen Dokument geändert 
wurden) den Benutzer fragen, ob er die Daten nicht doch lieber 
sichern möchte. 





h Änderungen von “Ohne Titel” sichern? 











| 
| 
| 
| 
Nicht Sichern] [Abbrechen 





Dies muß mit Hilfe eines Dialoges geschehen (siehe Abb. 9-8). 
Hat der Benutzer diesen Dialog mit "Nicht sichern" beantwortet, 
so kann das Fenster und alle Daten, die zu ihm gehören, freige- 
geben werden. 


Hat der Benutzer in die Grow-Region eines Fensters geklickt 
(FindWindow hat den Wert inGrow zurückgegeben), so reagiert 
das Programm, indem die Funktion GrowWindow aufgerufen 
wird. Diese Funktion übernimmt die Kontrolle und läßt den 
Benutzer mit Hilfe der Maus die Größe des Fensters verändern. 
Dies geschieht, indem das übliche graue Rechteck der Mausposition 
hinterhergezogen wird. 


pascal long GrowWindow ( WindowPtr theWindow, 
Point startPt, 
const Rect *bBox); 


Bei einem Aufruf von GrowWindow wird das Fenster, welches 
vergrößert oder verkleinert werden soll, durch theWindow an- 
gegeben. Hier übergibt man üblicherweise den Wert, der von 
FindWindow zurückgegeben wurde, wenn der Benutzer in die 
Grow-Region eines Fensters geklickt hat. Wie bei TrackBox oder 
TrackGoA way übergibt man die Startposition des Mausklicks in 
startPt. Das Rechteck, dessen Adresse bei bBox übergeben wird, 
ist die "Bounding-Box". Dieser Parameter gibt die erlaubte mini- 


male und die erlaubte maximale Größe des Fensters an. 
Die Felder top und left des Rects spezifizieren die minimale, 
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bottom und right die maximale Größe des Fensters. 

Der Ergebniswert von GrowWindow ist etwas "verschlüs- 
selt"; diese Funktion gibt einen long zurück, der gleichzei- 
tig die vom Benutzer ausgewählte neue horizontale wie auch 
die vertikale Größe des Fensters beinhaltet. Das Hi-Word 
dieses longs entspricht dabei der ausgewählten Höhe, das 
Lo-Word der gewünschten Breite des Fensters. Das Programm 





Minimum ZE 











muß anschließend den Ergebniswert "entschlüsseln" und 
die Funktion SizeWindow aufrufen, um das Fenster wirk- 
lich zu vergrößern. 


Mit Hilfe von SizeWindow kann die Größe eines Fensters verän- 
dert werden. Normalerweise wird diese Funktion in der Kette 
MouseDown>FindWindow->GrowWindow-SizeWindow 


aufgerufen. 

pascal void SizeWindow ( WindowPtr theWindow, 
short w, 
short h, 


Boolean £fÜpdate); 


Das Fenster, dessen Größe geändert werden soll, wird durch 
theWindow spezifiziert. Die neue Breite bzw. Höhe wird mit 
den Parametern w bzw. h angegeben. Der Parameter fUpdate gibt 
an, ob SizeWindow im Falle eines Vergrößerns des Fensters den 
neuen Bereich als Update-Event an das Programm schicken soll. 
Damit wird praktisch "automatisch" dafür gesorgt, daß der neu- 
zuzeichnende Bereich auch korrekt gemalt wird, weil das Pro- 
gramm ohnehin in der Lage sein muß, auf Update-Events zu 
reagieren. Damit SizeWindow diesen Update-Event generiert, 
übergibt man hier (eigentlich immer) den Wert true. Falls man 
dies nicht will (kommt sehr selten vor), so übergibt man den Wert 
false, ist dann aber auch selber dafür verantwortlich, eventuell 
neu entstandene Flächen auszurechnen und zu zeichnen. 


Hat der Benutzer in die Dragging-Region eines Fensters geklickt 
(FindWindow hat inDrag zurückgegeben), so ruft ein Mac-Pro- 
gramm die Funktion DragWindow auf, um dem Benutzer die 





Abb. 9-9 
GrowWindow in Aktion. 


SizeWindow 


DragWindow 
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Möglichkeit zu geben, das Fenster zu verschieben. DragWindow 
übernimmt die Kontrolle und verfolgt die Mausposition solan- 
ge, bis der Benutzer die Maustaste losgelassen hat. Währenddessen 
zeichnet DragWindow die grau gepunktete Umrandung des 
Fensters immer an der Stelle, die zur aktuellen Mausposition gehört. 
Hat der Benutzer die Maus in einem gültigen Bereich losgelassen, 
so verschiebt DragWindow das Fenster zu seiner neuen Positi- 
on. 


pascal void DragWindow ( 
windowPtr theWindow, 
Point startPt, 
const Rect *boundsRect); 


Das Fenster, welches der Benutzer verschieben möchte, wird durch 
den Parameter theWindow angegeben. Die Startposition wird (wie 
immer) mit startPt beschrieben (siehe GrowWindow etc.). Das 
Rechteck boundsRect gibt den Bereich an, in dem der Benutzer 
die Maus loslassen muß. Diese "Bounding-Box" muß in globalen 
Koordinaten (also Bildschirmkoordinaten) angegeben werden. 
Normalerweise möchte man dem Benutzer die Möglichkeit geben, 
das Fenster über den gesamten Bildschirm bzw. über alle Bild- 
schirme hinweg bewegen zu können. Man übergibt daher an dieser 
Stellenormalerweise das umschließende Rechteck aller Monitore. 
Dieses Rechteck kann man aus dem globalen QuickDraw-struct 
"gqd" unter "screenBits" herausfinden. screenBits ist eine Bit-Map 
(die Bildschirm-Bit-Map), welche ein bounds-Feld enthält (das 
umschließende Rechteck der Bit-Map). Dieses Rechteck der 
Bildschirm-Bit-Map ist genau das umschließende Rechteck aller 
Bildschirme in globalen Koordinaten, welches wir für den Auf- 
ruf von DragWindow benötigen. Normalerweise wird hier also 
die Adresse von qd.screenBits.bounds übergeben. 


9,3 Anwendung des Window-Managers 


Die erste Window-Manager-Funktion, die hier vorgestellt wird, 
ist die GetNewWindow-Funktion. Diese Funktion erzeugt auf 
der Grundlage eines Window-Templates (einer Window-Resource) 
ein neues Fenster. Da diese Funktion eine Resource zum Erzeu- 
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gen des Fensters benötigt, kann ihre Anwendung nicht mit ei- 
nem Programmfragment, sondern nur anhand eines kompletten 
Programms demonstriert werden. Dieses Programm braucht eine 
'WIND' (Window-Template)-Resource im Resource-Fork der 
Applikation. Setzen wir zunächst einmal das Vorhandensein dieser 
Resource voraus und implementieren das Programm: 

Das Programm muß zunächst die benötigten Manager initiali- 
sieren. Um ein Fenster zu öffnen, muß (verständlicherweise) der 
Window-Manager initialisiert werden. Der Window-Manager 
verwendet für das Zeichnen und Verwalten eines Fensters 
QuickDraw, also muß auch QuickDraw initialisiert werden. 
Weiterhin verwendet der Window-Manager indirekt den Font- 
Manager (um den Fenstertitel zu zeichnen), also muß auch die- 
ser initialisiert sein. 

Um überhaupt mit irgendwelchen ToolBox- oder QuickDraw- 
Aufrufen zu arbeiten, müssen zunächst die Interface-Dateien für 
diese Manager eingebunden werden. Diese Interface-Dateien 
enthalten sowohl die Datenstrukturen als auch die Einsprung- 
bzw. Trap-Adressen der ToolBox-Routinen, die zu dem jeweili- 
gen Manager gehören. Diese Interface-Dateien haben in der MPW- 
Shell den Namen des entsprechenden Managers und enden mit 
".h" für Header. 


1: #include "Types.h" Das Beispielprogramm 
F - en 2 a . initialisiert zunächst die 

: #include "Fonts.h" En 
4: #include "Windows.h" BEnORgIEN, Manager une 
= ruft anschließend die 
6: WindowPtr myWindow; Funktion 
7: GetNewWindow auf, 
8: void main (void) um auf der Grundlage 
9: f einer 'WIND'-Resource 
10: IuLLsret (gqd.thePort); EinRallassFonsterä 
11: InitFonts (); 
12: InitWindows (); BIZBUGEN: 
13: 
14: myWindow = GetNewwWindow (128, NULL, 

(windowPtr) -1); 

15: } 
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Die 'WIND'-Resource 
wird in einer Resource- 
Description-Datei 
beschrieben, die mit 
Hilfe von ResEdit und 
DeRez erzeugt wurde. 





Das Programm bindet mit den #include-Statements in Zeile 2 bis 
4 die benötigten Manager-Interface-Dateien (für QuickDraw, den 
Font-Manager und den Window-Manager) ein. Die Einbindung 
der "Types.h"-Datei in Zeile 1 bewirkt die Deklaration der wich- 
tigsten Basis-Datentypen wie Point oder Rect, die in vielen ande- 
ren Interface-Dateien vorausgesetzt werden. 

In Zeile 6 wird die Variable myWindow deklariert, um das von 
GetNewWindow erzeugte Fenster zu verwalten. Die Zeilen 10 
bis 12 initialisieren die benötigten Manager durch Aufruf der 
entsprechenden Initialisierungsroutinen. In Zeile 14 wird 
schließlich die Funktion GetNewWindow aufgerufen. Ihr wird 
als Resource-ID die ID der (vorausgesetzten) 'WIND'-Resource 
übergeben, welche die Position, Größe und Art des Fensters be- 
schreibt. In diesem Beispiel gehen wir von einer bestehenden 
'WIND'-Resource mit der ID 128 aus. 

Da anstelle des wStorage-Parameters NULL übergeben wird, 
alloziiert GetNewWindow einen nonrelocatable-Block für die 
Verwaltung unseres Fensters. Die Adresse dieses Blocks (also 
des WindowRecords) gibt GetNewWindow als Ergebniswert 
zurück. 

Für den Parameter behind wird der Wert -1 übergeben. Dies be- 
deutet, daß das neue Fenster über allen anderen, bereits beste- 
henden Fenstern erzeugt wird. Diese Zahl muß mit Hilfe von 
Type-Casting in einen WindowPtr verwandelt werden, um den 
Compiler zufrieden zu stellen. 


Um das Programm wirklich zum Leben zu erwecken, fehlt noch 
die Definition der vorausgesetzten 'WIND'-Resource und das 
Compilieren und Binden der Applikation. 

Die 'WIND'-Resource wird durch die folgende Resource- 
Description-Datei beschrieben. Die hier gezeigte Definition ei- 
ner 'WIND'-Resource wurde (wie im vorangegangenen Kapitel 
beschrieben) zunächst mit Hilfe von ResEdit in einer neuen 
Resource-Datei angelegt. 
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% File Edit Resource Window WIND MiniScreen 


Abb. 9-11 

Der WIND-Editor von 
Resedit. 

Hier kann man u.a. den 


— —— Fenstertyp, die Position 
mu mie [IA] und die Größe des 




















Color: ® Default Fensters interaktiv 
OÖ Custom ? 
einstellen. 
Tob: Height: & Initially visible 
Left: width: le 

Anschließend wurde unter Verwendung des DeRez-Tools die 
angelegte Resource in eine Resource-Description-Datei umge- 
wandelt und mit Kommentaren versehen. Diese Resource- 
Description-Datei kann jetzt in den Übersetzungsvorgang mit 
eingebunden werden. 

1: #include "Types.r" /* Typendeklarat. */ Die Resource- 

2: Description-Datei 

3: resource 'WIND' (128) { /* ResType, ID *%/ enthält die Definition der 

. * x 

4: {40, 40, 400, 440}, /* Umschl. Rechteck */ 'WIND'-Resource. Sie 

5; documentProc, /* Fenstertyp ur DER 

6: visible, /* Sichtbar #7 WU mEBNE Von 

7 noGoAway, /* kein Schließfeld */ DeRez decompiliert und 

8 0x0, /* RefCon *x/ mit Kommentaren 

9: "Minimum" /* Titel */ versehen. 

10% 7 


Diese Resource-Description-Datei beginnt mit der Einbindung 
der Resource-Typendeklarationsdatei "Types.r". In dieser Datei 
werden (ähnlich zu Types.h) Basis-Typen deklariert. Hier han- 
deltessich um Resource-Typendeklarationen wie die Deklaration 
der 'WIND'-Resource. Da der Resource-Compiler ein Typen- 


konzept unterstützt (vergleichbar mit C), verlangt er auch Ty- 171 
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Die Definition einer 
Resource beginnt 
immer mit dem 
Schlüsselwort 
resource’, gefolgt von 
dem Resource-Type und 
der (in Klammern 
gesetzten) Resource-ID. 
Nachfolgend wird die 
Resource selbst 
definiert; die geschweif- 
ten Klammern enthalten 
die Resource-spezifi- 
schen Informationen. 





pendeklarationen. Eine solche Typendeklaration (die des 'WIND'- 
Resource-Types) wird verwendet, um die Window-Resource zu 
definieren. Dies geschieht durch Verwendung des Resource- 
Description-Language-Keywords "resource" bzw. die folgende 
Spezifikation des zu definierenden Resource-Types (WIND') und 
die Bekanntgabe der Resource-ID (128) in Zeile 3. 

Alles, was zwischen der geschweiften Klammer am Ende der von 
Zeile 1 und der korrespondierenden schließenden Klammer in 
Zeile 10 steht, definiert die 'WIND'-Resource. 

Zunächst wird in Zeile 4 das umschließende Rechteck des Fen- 
sters, also Position und Größe, in globalen Koordinaten angege- 
ben. Dieses Rechteck (top, left, bottom, right) ist von der linken 
oberen Ecke des Hauptbildschirmes aus gesehen definiert. 

Das nachfolgende documentProc-Statement ist eine der vielen 
vordefinierten Resource-Konstanten. Die Verwendung von 
documentProc bewirkt, daß unser Fenster vom Typ document- 
Proc ist (siehe Anfang dieses Kapitels), dem normalen Macin- 
tosh-Fenstertyp. 

Das visible-Statement in Zeile 6 bedeutet, daß das Fenster sofort 
sichtbar wird. Man kann hier auch invisible angeben, dann wird 
das Fenster nicht sofort nach dem GetNewWindow-Aufruf 
sichtbar, sondern muß durch einen Aufruf von ShowWindow 
sichtbar gemacht werden. 

Das Statement noGoAway bewirkt, daß das Fenster noch keine 
Go-Away-Box besitzt (wir unterstützen sie ja noch nicht). 

Das 0x0 ist (wie in C) eine Hexadezimalkonstante und bedeutet 
den Wert 0. Der hier eingetragene Wert landet im refCon-Feld 
des WindowRecords. Um beispielsweise die verschiedenen Fen- 
ster einer Applikation durchzunumerieren, kann man hier die 
dem Fenster entsprechende Nummer eintragen. 

Das letzte Resource-Statement definiert den Namen des Fensters; 
der hier eingetragene String "Minimum" erscheint in der Titel- 
leiste des Fensters. 


Die Anwendung der übrigen Window-Manager-Funktionen, die 
zur Verwaltung des Fensters bestimmt sind, kann erst im nach- 
folgenden Kapitel beschrieben werden, da sie die Implementie- 
rung der Main-Event-Loop voraussetzt, welche im nächsten Ka- 
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pitel beschrieben wird. Dieses Kapitel begnügt sich mit der Er- 
stellung einer Experimentierplattform ("MINIMUM"). 


9,4 MINIMUM - Das "Hello World des Macintosh" 


Das Programm Minimum fügt die bisher beschriebenen Mana- MINIMUM ist das erste 
ger zu einer Experimentierplattform zusammen. Minimum er- konkrete Beispiel- 
öffnet ein Fenster, basierend auf einer 'WIND'-Resource, und bietet programm. Es erzeugt 
die Möglichkeit, mit QuickDraw oder anderen Managern zu ex- ein Fenster, in welchem 
perimentieren. Weiterhin ist dieses kleine Beispielprogramm die die ersten Experimente 
Basis der folgenden Erweiterungen in bezug auf Event-Verwal- mit QuickDraw stattfin- 
tung, Menu-Management und Controls. Die Erweiterungen die- den können. 

ses Programms führen schließlich zu der Basis-Applikation 

SKELETON, auf der Sie Ihre eigenen Projekte aufsetzen können. 

Minimum besteht aus zwei Dateien: 


1. Minimum.c 
Diese Datei enthält den C-Quelltext. 


2. Minimum.r 
Diese Resource-Description-Datei enthält die oben beschriebene 
Resource-Description der benötigten 'WIND'-Resource. 


Das Beispiel-Programm "Minimum" befindet sich auf der dem 
Buch beigelegten Beispieldiskette. Wenn Sie gerade in der Nähe 
eines Macintosh mit installierter MPW-Shell sitzen, dann probieren 
Sie doch einmal die folgenden (bereits im Kapitel über die MPW- 
Shell beschriebenen) Schritte zum Übersetzen der Beispielappli- 
kation aus: 


1. Kopieren Sie den Ordner Minimum von der Diskette auf die 
Festplatte. 

2. Starten Sie die MPW-Shell. 

3. Wählen Sie mit Hilfe des "Set Directory"-Menüpunktes aus dem 
"Directory"-Menü bzw. des folgenden Dialoges den Ordner Mi- 
nimum aus. 

4. Wählen Sie aus dem "Build"-Menü den Menüpunkt "Create 


Build Commands..." aus. 
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Abb. 9-12 

Die Abbildung zeigt das 
laufende Programm, 
bzw. das von dem 
Programm erzeugte 
Fenster. 


5. Klicken Sie in dem Dialog auf den "Sourcefiles..."-Button. 

6. Wählen Sie die Dateien "Minimum.r" und "Minimum.c" aus 
der Liste der Quelltexte aus und übernehmen Sie diese Dateien 
in die Liste der Quelltexte, indem Sie den "Add"-Button anklicken. 
7. Beenden Sie den Dialog mit "Done". 

8. Geben Sie in dem Edit-Feld "Program Name" den Programm- 
namen "Minimum" ein. 

7. Klicken Sie auf den "Create Make"-Button. 

8. Wählen Sie den Menüpunkt "Build" aus dem "Build"-Menü 
und bestätigen Sie den nachfolgenden Dialog mit "OK". 

9. Nachdem der Compiler erfolgreich durchgelaufen ist, starten 
Sie die Applikation, indem Sie die "Enter"-Taste (ganz rechts unten 
auf der erweiterten Tastatur) drücken. Haben Sie keine erweiter- 
te Tastatur (die mit den Funktionstasten wie bei einem IBM-PC), 
dann klicken Sie auf das "MPW Shell"-Feld im oberen, linken 
Rand des Fensters. 











Sie können das Programm verlassen, indem Sie die Maustaste 
drücken. 

Das Programm Minimum ist eine etwas erweiterte Version des 
oben vorgestellten Programms zum Erzeugen eines Fensters. Durch 
die Erweiterungen wird ein Problem gelöst, welches im oben be- 
schriebenen Beispielprogramm noch nicht berücksichtigt wur- 


de. Dieses Problem besteht darin, daß das bisher beschriebene 
Programm bei der Ausführung brav ein Fenster erzeugen, jedoch 
sofort, nachdem das Fenster auf dem Bildschirm erschiene, wie- 
der terminieren würde. Dies führt dazu, daß das Fenster nur für 
wenige Augenblicke sichtbar wird, da die Fenster eines termi- 
nierenden Programms auf dem Macintosh automatisch geschlossen 
werden. 

Minimum löst dieses Problem durch eine Anleihe bei dem im 
nächsten Kapitel beschriebenen Event-Manager. Das Programm 
besitzt zwar noch keine Main-Event-Loop, hat aber eine kleine 
Abfrageschleife, die solange läuft, bis der Benutzer die Maus- 
taste drückt. Solange dies nicht geschieht, terminiert das Pro- 
gramm nicht, und das Fenster bleibt sichtbar. Dieses Abfragen 
der Maustaste geschieht mit Hilfe der Event-Manager-Funktion 
Button, die dann true zurückgibt, wenn die Maustaste gedrückt 
ist. Der Quelltext zum Minimum-Programm sieht dement- 
sprechend folgendermaßen aus: 


: #include "Types.h" 

: #include "QuickDraw.h" 
: #include "Fonts.h" 

: #include "windows.h" 

: #include "Events.h" 


: WindowPtr myWindow; 


: void main (void) 

{ 
InitGraf (&qd.thePort); 
InitFonts (); 
InitWindows (); 


PFHrrrHr 
BWNHOVVO IN UWRWNDH 


myWindow = GetNewwWindow (128, NULL, 


(WindowPtr) -1); 


16: SetPort (myWindow) ; 

17: /* Hier ist Platz für Experimente */ 
18: while (Button () == false); 

19%; 7} 


In Zeile 5 ist das #include-Statement für die Header-Datei des 
Event-Managers hinzugefügt worden. Durch diese Header-Da- 
tei wird dem Compiler die Button-Funktion bekannt gemacht, 


9.4 MINIMUM - Das 





"Hello World" des Mac 


Der Quelltext des 
Programms MINIMUM. 
Das Programm 
entspricht dem oben 
beschriebenen Beispiel- 
programm zur Erzeu- 
gung eines Fensters, 
verwendet jedoch 
zusätzlich die Funktion 
Button 

(als Terminations- 
kriterium). 
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welche in Zeile 18 benutzt wird, um die Maustaste abzufragen, 
bzw. ein frühzeitiges Terminieren der Applikation zu verhin- 
dern. 

Zeile 16 fügt noch die QuickDraw-Funktion SetPort hinzu. Der 
Aufruf dieser Funktion sorgt dafür, daß unser neuerzeugtes Fenster 
auch die aktuelle Zeichenumgebung ist. Durch den Aufruf von 
SetPort wird das Koordinatensystem auf unser Fenster umge- 
schaltet, die Zeichenbegrenzungen (Clipping-Region etc.) wer- 
den dadurch ebenfalls auf die unseres Fensters gesetzt. 


An dieser Stelle möchte ich Sie zum Experimentieren mit Quick- 
Draw einladen. Wenn Sie einen Mac mit installierter MPW-Shell 
bereitstehen haben, so können Sie auf der Basis dieses kleinen 
Programms erste Versuche starten. Am besten eignet sich 
QuickDraw für diese Experimente, da hier schnell sichtbare Er- 
gebnisse erzielt werden können. 

Beispiele für Aufgaben wären u.a. das Zeichnen von Linien, ei- 
nes Kreises oder auch kompliziertere Dinge, wie das Zeichnen 
eines Polygons, oder die Aufzeichnung eines Pictures. 
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Dieses Kapitel beschäftigt sich mit der Implementierung der Main- 
Event-Loop. Diese zentrale Schaltstelle eines Macintosh-Pro- 
gramms bezieht ihre Informationen aus den sogenannten "Events". 
Diese Events (Ereignisse) sind eine universelle Schnittstelle für 
Systeminformationen sowie Benutzereingaben. Die Main-Event- 
Loop ist sozusagen der "Trichter" für Kommandos, die an ein 
Macintosh-Programm geschickt werden. In ihr bekommt das 
Programm seine Befehle und reagiert mit den korrespondieren- 
den Aktionen. 


10.1 Der Event-Manager 


Der Event-Manager bildet die Schnittstelle zwischen Benutzer 
und Programm. Über die verschiedenen Routinen und Daten- 
strukturen dieses Managers bekommt das Programm seine Befehle 
vom Benutzer. Ein typisches Macintosh-Programm befindet sich 
solange wartend in der Main-Event-Loop, bis es auf sein ständiges 
Fragen nach einem vorliegenden Event eine positive Antwort 
des Event-Managers erhält. Das Programm bekommt den vor- 
liegenden Event vom Event-Manager geliefert und verzweigt in 
die entsprechenden Event-Behandlungsroutinen. 

Der Event-Manager verwaltet eine Event-Queue (eine Ereignis- 
Schlange), in der sämtliche anfallenden Events gespeichert werden. 
Werden die Events schneller erzeugt als abgearbeitet, so werden 
die unterschiedlichen Events nach ihren Prioritäten geordnet in 
der Event-Queue aufbewahrt, bis das Programm sie "abholt". Diese 
Priorisierung der Events stellt den Benutzer in den Vordergrund; 
sehr hoch in der Prioritätenliste stehen die MouseDown-Events, 
sie "überholen" beispielsweise wartende Update-Events. Der 177 





Die Event-Priorisierung 
stellt den Benutzer in 
den Vordergrund; 
MouseDown-Events 
"überholen" die weniger 
wichtigen Update- 
Events. 

Diese Technik stellt eine 
wichtige Säule des 
Responsiveness-Gebots 
dar. 


Die Funktion 
WaitlNextEvent ist die 
'Zentrale" des Event- 
Managers. Durch einen 
Aufruf dieser Funktion 
gelangt das Programm 
an den nächsten Event. 


Hintergrund dieser Priorisierung läßt sich am besten an einem 
Beispiel verdeutlichen: 

Wenn der Benutzer ein Fenster verschoben hat, so daß andere 
(vormals verdeckte) Fenster freigelegt werden, so generiert das 
System eine Reihe von Update-Events für die freigelegten Fenster. 
Ist der Bildschirm mit Fenstern überfüllt, so kann das Verschie- 
ben eines Fensters durchaus 20 oder 30 Update-Events auslösen, 
deren Abarbeitung (je nach Rechnertyp) einige Sekunden bean- 
spruchen kann. Wenn der Benutzer während der Abarbeitung 
der Update-Events die Maustaste drückt, um z.B. ein Menü aus- 
zuwählen, so überholt der MouseDown-Event die wartenden 
Update-Events. Durch diese Priorisierung wird das Menü her- 
untergeklappt, bevor der Inhalt der freigelegten Fenster restau- 
riert wird. Dieses Verhalten des Event-Managers stellt damit eine 
Implementierung des Responsiveness-Gebotes dar. Der Rechner 
soll möglichst direkt (und ohne zeitliche Verzögerung) auf die 
Aktionen des Benutzers reagieren. Wenn der Event-Manager die 
Events streng nach der Reihenfolge ihres Auftretens an das Pro- 
gramm liefern würde, so würde das Programm in der oben be- 
schriebenen Situation einige Sekunden lang nicht auf die Aktion 
des Benutzers (Klick in die Menüleiste) reagieren. Stattdessen 
würde es die (weniger wichtigen) Update-Events abarbeiten. Ein 
solches benutzer-unfreundliches Verhalten wird durch den Event- 
Manager mit Hilfe der Event-Priorisierung verhindert. 


10.2 WaitNextEvent 

Der Event-Manager stellt eine zentrale Routine zur Verfügung, 
welche die Schnittstelle zur Event-Behandlung darstellt. Diese 
Funktion namens WaitNextEvent ist der "Trichter", durch den 
Benutzereingaben und andere Befehle an ein Macintosh-Programm 
gelangen. Ein Macintosh-Programm ruft die Funktion Wait- 
NextEvent aus der Main-Event-Loop heraus auf, um an den 
nächsten Event zu gelangen. Die aufgetretenen Ereignisse (Events) 
werden von dieser Routine in Form eines EventRecords (die 
zentrale Datenstruktur des Event-Managers) an das Programm 
geliefert. 


WaitNextEvent übernimmt bei einem Aufruf die Kontrolle und 
stellt den im Hintergrund laufenden Prozessen Rechenzeit zur 
Verfügung, wenn kein Event vorliegt. WaitNextEvent bildet also 
nicht nur die Schnittstelle zu den Events, sondern ist gleichzeitig 
die Schnittstelle zum Cooperative-Multitasking des Macintosh. 


pascal Boolean WaitNextEvent ( 


short eventMask, 
EventRecord *theEvent, 
unsigned long sleep, 

RgnHandle mouseRgn); 


Liegt ein Event vor, so gibt die Funktion den Wert true zurück. 
In diesem Fall enthält der EventRecord, dessen Adresse bei 
theEvent übergeben wurde, den aufgetretenen Event. Das Pro- 
gramm muß in diesem Fall die EventRecord-Datenstruktur 
analysieren und die entsprechenden Event-Behandlungsroutinen 
aufrufen. 

Das Programm kann bei einem Aufruf dieser Funktion mit Hilfe 
des eventMask-Parameters spezifizieren, welche Arten von Events 
es behandeln kann. Dieser Parameter stellt eine Art Filter für die 
Events dar; nur die Events, die durch diesen Filter passen, wer- 
den an das Programm zurückgegeben, alleanderen Events werden 
ignoriert, verbleiben aber in der Event-Queue. Ein Macintosh- 
Programm muß alle Events abfragen, auch wenn sie nicht behandelt 
werden. In der Regel wird anstelle dieses Parameters daher die 
vordefinierte Konstante everyEvent übergeben, die sämtliche 
Event-Arten an das Programm weitergibt. 

Der vorletzte Parameter der Funktion WaitNextEvent (sleep) gibt 
die "Wunsch-Hintergrundzeit" an, die den im Hintergrund lau- 
fenden Programmen zur Verfügung gestellt werden soll. Diese 
Zeit (in Ticks = 1/60 Sekunden) wird auf die im Hintergrund 
laufenden Programme verteilt. Mit dieser Zeitkonstanten kann 
das im Vordergrund laufende Programm die Aktivität der 
Hintergrundprogramme steuern. Ein.ausgeklügeltes Macintosh- 
Programm übergibt bei diesem Parameter eine Variable, deren 
Wert schrittweise bis zu einem Maximum erhöht wird, wenn keine 
Events vorliegen. Treten dann wieder Events auf, so setzt das 
Programm diese Wunsch-Hintergrundzeit abrupt zurück. Auf 
diese Weise wird die Rechenzeit immer optimal genutzt. Treten 


10.2 WaitNextEvent 





WaitlNextEvent liefert die 
Informationen über 
einen Event in Form 
eines EventRecords (der 
zentralen Datenstruktur 
des Event-Managers) an 
das Programm. 


Bei einem Aufruf von 
WaitlNextEvent kann das 
im Vordergrund 

laufende Programm 
spezifizieren, wieviel Zeit ' 
den Hintergrundprozes- 
sen zur Verfügung 

gestellt wird. 
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Abb. 10-1 

Die Grafik zeigt das 
Verhalten einer 
ausgereiften Macintosh- 
Applikation: Der Wert 
von sieep wird schritt- 
weise heraufgesetzt, 
solange keine Events 
vorliegen. Tritt dann ein 
Event auf, so wird diese 
"Wunsch-Hintergrund- 
zeit" abrupt zurückge- 
setzt. 
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keine Events auf, so steigt die Aktivität der Hintergrundprozesse, 
drückt der Benutzer dann beispielsweise die Maustaste, so sinkt 
die Aktivität der Hintergrundprozesse wieder. 


sleep Event 





Der letzte Parameter, der an WaitNextEvent übergeben werden 
muß, kann ein RegionHandle sein. In dieser Region kann das 
Programm spezifizieren, daß es vom Event-Manager mit einem 
Event davon informiert werden möchte, wenn der Maus-Cursor 
diese Region verläßt. Viele Macintosh-Programme übergeben 
hier eine Region, die dem Bereich entspricht, in dem die Cursor- 
Form konstant bleiben soll. Verläßt der Maus-Cursor diese Region, 
so bekommt das Programm einen MouseMoved-Event und 
analysiert die neue Cursor-Position, um dem Cursor eventuell 
eine neue Form zu geben. 

Diese Technik spart eine Menge Rechenzeit, da das Programm 
nur dann die Cursor-Position analysieren muß (um eventuell die 
Form des Cursors zu ändern), wenn es einen MouseMoved-Event 
bekommt. 


10.3 Der EventRecord 

Die zentrale Datenstruktur des Event-Managers ist (wie schon 
erwähnt) der EventRecord. Dieser EventRecord ist eine univer- 
selle Datenstruktur, in der die verschiedenen Events "verpackt" 
werden. Die Events werden von der (gerade beschriebenen) 
WaitNextEvent-Funktion in Form eines EventRecord an das 
Programm geliefert. Ein EventRecord ist wie folgt deklariert: 


loc H BT] 4 SS -Taliat-terolge| 





1: struct EventRecord { 

. nn t what; Der EventRecord ist die 
: a ae zentrale Datenstruktur 

4: long when; 

5 Beine where; des Event-Managers. 

6: short modifiers : Ein EventRecord enthält 

le} sämtliche Informationen 


über einen Event; durch 
Das Feld what dient dazu, die verschiedenen Events voneinan- _ diese zentrale Struktur 
der zu unterscheiden. Anhand dieses Feldeskann dasProgramm _ erhält das Programm 
entscheiden, ob es sich bei dem vorliegenden Event beispiels- seine Befehle. 
weise um einen MouseDown- oder einen Update-Event handelt. 
Das Feld message enthält je nach Event verschiedene Informa- 
tionen. Bei einem KeyDown-Event enthält es beispielsweise In- 
formationen über die gedrückte Taste, bei einem Update-Event 
über das Fenster, welches neu gezeichnet werden soll. Dieses 
Feld ist damit ein Universalfeld, dessen Inhalt mit Hilfe von Type- 
Casting in die entsprechenden Typen verwandelt wird. Im Falle 
eines Update-Events enthält dieses Feld beispielsweise einen 
WindowPtr (die Adresse eines WindowRecords). Um mit diesem 
als long deklarierten Feld wie mit einem WindowPtr arbeiten zu 
können, wird es mit Hilfe von Type-Casting in einen WindowPtr 
verwandelt. 
Das Feld when gibt Informationen über den Zeitpunkt des Events. 
Dieses Feld wird hauptsächlich dazu verwendet, Einfachklicks 
von Doppelklicks anhand des Zeitunterschiedes zwischen den 
einzelnen MouseDown-Events zu unterscheiden. Die "Human 
Interface Guidelines" besagen, daß ein Doppelklick immer die 
Erweiterung eines Einfachklicks sein muß. Dies bedeutet, daß 
der erste Klick einer Doppelklick-Sequenz zunächst als ganz 
normaler Klick behandelt wird und dem Benutzer eine entspre- 
chende Rückmeldung gegeben wird. Erst das Eintreffen des 
zweiten MouseDown-Events führt zu der Doppelklick-Reaktion. 
Ein Beispiel für die Implementierung dieser Guidelines ist u.a. 
im Finder zu finden; hier bewirkt der erste Klick einer Doppelklick- 
Sequenz auf einen Ordner zunächst das normale Auswählen des 
Ordners, erst der zweite Klick öffnet den (jetzt selektierten) Ordner. 
Das Feld where spezifiziert die Position der Maus zur Zeit des 
Events. Im Falle eines MouseDown- oder MouseUp-Events ent- 


hält dieses Feld die globalen Koordinaten des Maus-Cursors. 
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Diese Konstanten 
werden durch ein 
logisches "und" mit dem 
moditiers-Feld des 
EventRecords verknüpft, 
um herauszufinden, ob 
eine der Spezialtasten 
gedrückt worden ist. 





Das letzte Feld eines EventRecords (modifiers) ist ein Bit-Feld. 
Die einzelnen Bits dieses shorts reflektieren den Zustand der 
sogenannten "Modifier"-Tasten (Befehls-, Wahl- und Umschalt- 
taste), während der Event aufgetreten ist. Für die Überprüfung 
der einzelnen Modifier-Tasten, können die folgenden Konstan- 
ten verwendet werden, die als Maske für das modifiers-Feld 
verwendet werden: 


#define cmdKey 25 /* Befehlstaste “/ 
#define shiftKey 512 /* Umschalttaste */ 
#define alphalock 1024 /* Feststelltaste */ 
#define optionkey 2048 /* Wahltaste */ 


#define controlKey 4096 /* Kontrolltaste */ 


Diese Modifier-Flags werden bei einem KeyDown-Event dazu 
verwendet, um Tastatureingaben von Menü-Kurzbefehlen zu 
unterscheiden. 

Bei einem MouseDown-Event können sie zur Unterscheidung 
zwischen Shift (Umschalttaste) -Klicks und normalen Klicks 
verwendet werden. In einem Textverarbeitungsprogramm führt 
ein einfacher Klick in den Text, beispielsweise zur Positionierung 
der Einfügemarke. Ein Shift-Klick selektiert den Text, der zwischen 
der aktuellen Position der Einfügemarke und dem Mausklick liegt. 


10.4 Die verschiedenen Events 


Zur Unterscheidung der verschiedenen Events stehen die fol- 
genden Konstanten zur Verfügung, die mit dem Feld what eines 
EventRecord verglichen werden können: 


#define nullEvent 0 


Das Programm kann sich bei einem Null-Event um weniger 
wichtige, aber periodisch auszuführende Aufgaben kümmern. 
Diese Null-Events werden von vielen Programmen dazu ver- 
wendet, um beispielsweise für das Blinken der Texteinfügemarke 
zu sorgen. Für die Implementierung einer blinkenden Einfüge- 
marke wird die (später beschriebene) Funktion GetCartetTime 
verwendet. Diese Funktion gibt das vom Benutzer eingestellte 


Einfügemarken-Blinkintervall zurück. Der Ergebniswert dieser 
Funktion stellt die Zeitdifferenz dar, die zwischen den beiden 
Zuständen der Einfügemarke liegen soll. Um das eingestellte 
Zeitintervall einzuhalten, wird die Differenz zwischen der letz- 
ten Idle-Event-Zeit, bei der die Einfügemarke invertiert wurde, 
und der Zeit des aktuellen Idle-Events ausgerechnet. Ist diese 
Zeitdifferenz (die sich aus dem when-Feld der Event-Records 
bilden läßt) größer als die von GetCartetTime zurückgegebene 
Zeit, so invertiert das Programm die Einfügemarke. 


#define mouseDown 1 


Der Benutzer hat die Maustaste gedrückt. Das Programm muß 
jetzt mit Hilfe der Window-Manager-Funktion FindWindow 
entscheiden, in welchem Bereich des Bildschirms (Fensterinhalt, 
Titelleiste, Controls, Menüs etc.) der Mausklick lag, und die 
entsprechenden Behandlungsroutinen aufrufen. 

Das Feld where des EventRecords gibt bei einem MouseDown- 
Event die Koordinaten des Mausklicks (in globalen Koordina- 
ten) an. Dieser Point kann direkt an die Funktion FindWindow 
übergeben werden, um den getroffenen Bildschirmbereich her- 
auszufinden. 

Um Doppelklicks von Einfachklicks zu unterscheiden, muß ein 
Programm stets die Position und die "Uhrzeit" des letzten Maus- 
klicks zwischenspeichern. Die Uhrzeit eines Mausklicks wird in 
dem Feld when eines EventRecords angegeben. Die Differenz der 
when-Felder zweier Mausklicks muß kleiner sein als der 
Ergebniswert der Funktion GetDbITime, die das vom Benutzer 
(im Kontrollfeld "Maus") eingestellte Doppelklick-Zeitintervall 
zurückgibt. Um einen Doppelklick von zwei Einfachklicks zu 
unterscheiden, müssen weiterhin die Positionen der beiden 
Mausklicks in einem Rechteck von weniger als 4 mal 4 Punkten 
liegen. Die Differenz zwischen den horizontalen bzw. den verti- 
kalen Koordinaten der beiden MouseDown-Events darf also nicht 
größer als 4 Punkte sein. Dieses Rechteck aus 4 mal 4 Punkten ist 
die Fehlertoleranz, die dem Benutzer bei einem Doppelklick ein- 
geräumt wird. 

Einige Programme unterscheiden auch noch zwischen norma- 
len Mausklicks und sogenannten "Command"-, "Option"-, oder 


10.4 Die verschiede- 


nen Events 





Idle-Events können für 
die Erledigung 
Zyklischer Aufgaben mit 
niedriger Priorität 
verwendet werden (z.B. 
das Blinken der 
Einfügemarke). 


MouseDown-Events 
treten dann auf, wenn 
der Benutzer die 
Maustaste gedrückt hat. 


Um Doppelklicks von 
Einfachklicks zu 
unterscheiden, wird das 
Feld when des 
EventRecords inspiziert, 
welches die "Uhrzeit" 
des Events enthält. 

Ein Doppelklick liegt 
dann vor, wenn die 
Zeitdifferenz zwischen 
zwei Mausklicks klein 
genug war, und die 
Positionen nahe genug 
beieinander lagen. 
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Wenn der Benutzer die 
Maustaste wieder 
losläßt, bekommt das 
Programm einen 
MouseUp-Event. 


Wird die Tastatur 
betätigt, dann bekommt 
das Programm einen 
KeyDown-Event für 
jeden einzelnen 
Buchstaben. 


"Shift"-Klicks. Wird eine der Modifier-Tasten (Befehlstaste, 
Wahltaste oder Umschalttaste) gedrückt gehalten, wenn die 
Maustaste gedrückt wird, so reagieren diese Programme anders 
als bei einem normalen MouseDown-Event. Ein Command,- 
Option- oder Shift-Klick kann durch Überprüfen des modifiers- 
Feldes des EventRecords von einem normalen Klick unterschie- 
den werden. 


#define mouseUp 2 


Dieser Event folgt auf einen MouseDown-Event, wenn der Be- 
nutzer die Maustaste wieder losgelassen hat. Er wird von vielen 
Programmen benutzt, um das Ende eines Mouse-Trackings zu 
erkennen. Dieses Mouse-Tracking ist beispielsweise in Zeichen- 
programmen während des sogenannten "Sketchings" (dem 
Zeichnen von Objekten mit Hilfe der Maus) zu finden. Das Pro- 
gramm beginnt das Mouse-Tracking durch einen MouseDown- 
Event und zeichnet beispielsweise ein Rechteck von der ur- 
sprünglichen Mausposition zur aktuellen Position, bis ein 
MouseUp-Event eintrifft. Dieser Event markiert dann das Ende 
des Sketchings (die Zeichenaktion ist beendet und das Rechteck 
definiert). 


#define keyDown 3 


Textverarbeitungsprogramme verwenden diesen Event, um dem 
Benutzer die Texteingabe zu ermöglichen. Drückt der Benutzer 
ein Taste auf der Tastatur, so bekommt das Programm einen 
KeyDown-Event. Der EventRecord enthält bei dieser Art von 
Events im Feld message Informationen über die gedrückte Ta- 
ste. Das Lo-Byte des Lo-Words dieses long-Feldes enthält den 
Character-Code (ASCII-Wert), das Hi-Byte des Lo-Words ent- 
hält den Key-Code (Tastatur-Matrix-Koordinaten) der gedrück- 
ten Taste. Normalerweise wird nur der Character-Code zur 
Texteingabe verwendet. Der Event-Manager stellt für das Aus- 
filtern des ASCII-Wertes die Konstante charCodeMask zur Ver- 
fügung, die zur Maskierung des message-Feldes verwendet wird. 
Um Menükurzbefehle (wie z.B. Befehlstaste-Q für "Beenden") von 
normalen Tastatureingaben zu unterscheiden, kann das Feld 


modifiers verwendet werden. Enthält das Feld ein auf 1 gesetz- 
tes Command-Key-Flag, so sollte das Programm den Menu- 
Manager nach dem äquivalenten Menüpunkt fragen. Diese 
"Command-Key-KeyDown-Events" werden also nicht zur nor- 
malen Texteingabe verwendet, sondern führen mit Hilfe des Menu- 
Managers zur Auswahl eines Menüpunktes. 


#define keyUp 4 


Dieser Event wird nur von ganz wenigen Applikationen beach- 
tet. Er tritt auf, wenn der Benutzer eine gedrückte Taste wieder 
losläßt. Diese Art von Events werden eigentlich nur von Musik- 
programmen behandelt, die die Tastatur als Musik-Keyboard 
umfunktionieren. 


#define autoKey 5 


Wenn der Benutzer eine Taste der Tastatur lange genug gedrückt 
hält, so spricht die automatische Zeichenwiederholung (Auto- 
Repeat) an. Die vom System generierten Key-Events werden dann 
als AutoKey-Event deklariert, um automatische Zeichenwieder- 
holung von normaler Zeicheneingabe unterscheiden zu können. 
Die meisten Programme behandeln AutoKey-Events genau wie 
KeyDown-Events, die übrigen Felder des EventRecords ent- 
sprechen auch dem normalen KeyDown-Event. 


#define updateEvt 6 


Wenn der Benutzer ein Fenster verschiebt, so daß andere Fenster 
freigelegt werden, generiert der Window-Manager einen Update- 
Event. Das message-Feld des EventRecords spezifiziert dann das 
Fenster, dessen Inhalt neugezeichnet werden soll. Das Univer- 
salfeld message enthält in diesem Fall einen Pointer auf den 
WindowRecord des neuzuzeichnenden Fensters. Ein Macintosh- 
Programm reagiert auf diesen Event, indem die Window-Mana- 
ger-Funktion BeginUpdate aufgerufen (setzt die Visible-Region 
auf den neuzuzeichnenden Bereich) und der gesamte Inhalt des 
Fensters gemalt wird. Anschließend ruft das Programm EndUpdate 
auf, um die Visible-Region des Fensters wieder auf den ur- 
sprünglichen Zustand zurückzusetzen. 


10.4 Die verschiede- 


nen Events 





Wenn der Benutzer die 
Befehlstaste gedrückt 
hält, während er eine 
Taste betätigt, dann 
muß das Programm den 
KeyDown-Event wie 
einen Menükurzbefehl 
behandeln. 


Wenn das Auto-Repeat 
der Tastatur anspricht, 
bekommt das Pro- 
gramm AutoKey-Events 
anstelle von KeyDown- 
Events. 


Wenn Teile eines 
Fensters neu gezeichnet 
werden müssen, 
bekommt das Pro- 
gramm einen Update- 
Event. 
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Wird eine Diskette 
eingelegt, dann wird 
dem Programm ein 
DiskInserted-Event 
geschickt. 


Abb. 10-2 

Wenn die eingelegte 
Diskette nicht lesbar ist, 
sollte das Programm 
DiIBadMount aufrufen, 
um dem Benutzer die 
Möglichkeit zum 
Initialisieren zu geben. 


Ist die Fensterhierarchie 
verändert worden, dann 
verschickt der Window- 
Manager Activate- 
Events. 
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#define diskEvt 7 


Wenn der Benutzer während des Programmablaufes eine Dis- 
kette einlegt, so bekommt das Programm einen DiskInserted-Event. 
Die meisten Programme interessieren sich nicht für den eigentli- 
chen Sinn dieses Events (das Einlegen einer Diskette), er wird 
hauptsächlich von Kopierprogrammen verwendet. 

Ein normales Programm muß diesen Event jedoch trotzdem be- 
handeln, da der Benutzer auch eine unformatierte Diskette ein- 
gelegt haben kann. In diesem Fall ist das Hi-Word des message- 
Feldes ungleich 0 und das Programm muß dafür sorgen, daß der 
Disketten-Initialisierungs-Dialog auf dem Bildschirm erscheint. 
Dies ist zum Glück recht einfach durch den Aufruf der Disk- 
Initialisation-Package-Routine DIBadMount zu erledigen. 





$ i ö 
& Das Volume ist nicht lesbar: 


Volume initialisieren? 


| Auswerfen ) 


oo 


Initialisieren 





#define activateEvt 8 


Wenn der Benutzer ein Fenster nach vorne geholt hat, schickt 
der Window-Manager dem Programm einen Activate-Event für 
dieses Fenster. Das Programm sollte dann (den Human Interface 
Guildelines entsprechend) die Scrollbars dieses Fensters zeigen 
und Selektionen (selektierter Text oder Grafik) zeichnen. 

Ein DeActivate-Event ist das Gegenstück zu einem Activate-Event. 
Wird ein Fenster in den Hintergrund geschickt, so bekommt das 
Programm einen DeActivate-Event für dieses Fenster. Es sollte 
dann die Scrollbars dieses Fensters verstecken und Selektionen 
aufheben. Diese DeActivate-Events werden in Form eines Activate- 
Events geschickt. Bisher wurden diese beiden Variationen des 
Activate-Events zum besseren Verständnis als separate Events 
beschrieben. Ein DeActivate-Event kann von einem Activate-Event 
unterschieden werden, indem das modifiers-Feld des Event- 
Records untersucht wird. Ist der Activate-Event eigentlich ein 
DeActivate-Event, so enthält das niederwertigste Bit desmodifiers- 
Feldes eine 1. An diesem Bit bzw. mit Hilfe der vordefinierten 


10.5 Weitere Event- 


Manager-Routinen 





Maske activateFlag kann zwischen Activate- und DeActivate- 
Events unterschieden werden. 


10.5 Weitere Event-Manager-Routinen 


Der Event-Manager bietet (neben der zentralen Datenstruktur 
des EventRecords bzw. der Routine WaitNextEvent) einige weitere 
Utility-Funktionen, die an verschiedenen Stellen der Macintosh- 
Programmierung recht nützlich werden können. Die wichtigsten 
dieser Routinen bzw. deren Anwendung werden jetzt beschrie- 
ben, bevor der restliche Teil dieses Kapitels sich mit der Imple- 
mentierung der Main-Event-Loop beschäftigt. 


Die Routine GetMouse liefert die aktuellen Koordinaten derMaus. GetMouse 
pascal void GetMouse (Point *mouseLoc); 


GetMouse schreibt die aktuellen Mauskoordinaten in den Point, 
dessen Adresse bei mouseLoc übergeben wird. Wichtig ist, daß 
diese Koordinaten (im Gegensatz zum MouseDown-Event) auf 
das lokale Koordinatensystem des aktuellen Fensters bezogen 
sind. 

Diese Routine wird in einigen Programmen dazu verwendet, die 
Mausposition während der Selektion oder während der Eingabe 
von grafischen Daten zu verfolgen. 


Die Funktion Button kann dazu verwendet werden, denaktuellen Button 
Status der Maustaste abzufragen. 


pascal Boolean Button (void); 


Diese Funktion gibt den Wert true zurück, wenn die Maustaste 
gedrückt ist. 


Um die maximale Zeitdifferenz, diezwischen zweiMouseDown- GetDblTime 
Events liegen darf, damit sie noch als Doppelklick interpretiert 
werden können, herauszufinden, steht die Funktion GetDbITime 
zur Verfügung. 
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pascal long GetDblTime (void); 

Diese Funktion liefert das vom Benutzer im Kontrollfeld "Maus" 
eingestellte Doppelklick-Zeitintervall zurück. Der Rückgabe-Wert 
dieser Funktion wird mit der Zeitdifferenz, die zwischen zwei 
MouseDown-Events liegt, verglichen. Ist die Differenz kleiner 
als der Rückgabe-Wert der Funktion GetDbITime, so ist der zweite 
MouseDown-Event ein Doppelklick. Bei der Erkennung von 
Doppelklicks ist (wie oben beschrieben) weiterhin darauf zu achten, 
daß die Position der beiden Klicks innerhalb eines 4 mal 4 Punk- 
te messenden Quadrates liegt. 


Textverarbeitungsprogramme müssen selbst für das Blinken der 
Einfügemarke sorgen. Da das Intervall für das Blinken der Ein- 
fügemarke im Kontrollfeld "Einstellungen" vom Benutzer ver- 
ändert werden kann, sollten Macintosh-Programme die Funk- 
tion GetCaretTime dazu verwenden, um die Zeitintervalle für 
das Blinken der Einfügemarke herauszufinden. 


pascal long GetCaretTime (void); 


Der Ergebniswert dieser Funktion wird dann mit der Zeitdiffe- 
renz zweier Idle-Events verglichen, um zu entscheiden, ob die 
Einfügemarke invertiert werden soll, oder obnoch gewartet werden 
muß. Die "Uhrzeit" (when-Feld des Event-Records) des letzten Idle- 
Events, bei dem die Einfügemarke invertiert wurde, wird dafür 
üblicherweise in einer Variablen zwischengespeichert. 


10.6 Anwendung des Event-Managers 

Die wichtigste Anwendung des Event-Managers besteht im Aufbau 
der "berüchtigten" Main-Event-Loop eines Macintosh-Programms. 
Diese Main-Event-Loop wird im folgenden Beispielprogramm 
demonstriert: 


: EventRecord 
: Boolean 


gEvent; 
gQuit, gGotEvent; 


: void main (void) 


10.6 Anwendung des 


SEWSNERELIE 





5: 

6: gQuit =. false; 

1: while (!gQuit) Die Main-Event-Loop 

8: { eines Macintosh- 

98 gGotNewEvent = WaitNextEvent ( Programms ruft 

everyEvent, &gEvent, 15, NULL); WaitNextEvent auf und 

40: EEMISSERNERT verzweigt anschließend 
11% HandleEvent (gEvent); j 
12: } in Event-Behandlungs- 
13: } routinen. 


Dieser Programmtorso stellt die einfache Version einer Main-Event- 
Loop dar. 

Das Programm ist eine Endlosschleife, die nur dann terminiert, 
wenn bei der Auswahl des "Beenden"-Menüpunktes der Boolean 
gQuit auf true gesetzt wird. Solange dies nicht der Fall ist, fragt 
das Programm in Zeile 9 mit Hilfe der Funktion WaitNextEvent 
beim Event-Manager nach, ob ein Event vorliegt. In diesem Beispiel 
gibt das Programm beim Aufruf der WaitNextEvent-Funktion an, 
daß es sämtliche Arten von Events behandeln möchte, indem 
die Konstante everyEvent übergeben wird. WaitNextEvent lie- 
fert also alle auftretenden Events an das Programm zurück. 
Hat WaitNextEvent einen Event für das Programm, so schreibt 
es die Informationen über den Event in dem EventRecord gEvent 
und gibt true als Ergebniswert zurück. Als "Wunsch-Hinter- 
grundzeit" wird hier (um das Beispiel zu vereinfachen) eine 
konstante Einheit von 15 Ticks übergeben. Diese Konstante ist 
ein von Apple vorgeschlagener Richtwert, der Hintergrund- 
prozessen zur Verfügung gestellt werden sollte. Die Möglich- 
keit des Event-Managers, das Programm mit einem MouseMoved- 
Event davon zu informieren, daß der Maus-Cursor einen be- 
stimmten Bereich verlassen hat, wird hier noch nicht verwendet, 
daher wird anstelle von mouseRegion der Wert NULL überge- 
ben. 

Liegt ein Event vor (gGotEvent == true), so wird in Zeile 11 in 
die (noch zu implementierende) Event-Behandlungsroutine 
verzweigt, um auf den Event zu reagieren. Diese Event-Behand- 
lungsroutine inspiziert die Art des Events und verzweigt dann 
wiederum in (spezialisiertere) Behandlungsroutinen. 
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Abb. 10-4 

Die Grafik zeigt das 
laufende Programm. Die 
Unterschiede zur 
vorhergehenden Version 
sind deutlich sichtbar: 
Das Fenster hat jetzt 
eine Glose- , Zoom- und 
Grow-Box. Die wichtig- 
sten Funktionalitäten 
des Window-Managers, 
wie Verschieben/ 
Vergrößern eines 
Fensters, sind unter- 
stützt. 


10.7° MINIMUM2 


MINIMUM? ist eine Erweiterung des Basisprogramms MINIMUM. 
Durch diese Erweiterung wird die Event-Behandlung (Main-Event- 
Loop und Behandlungsroutinen) in das kleine Beispiel-Programm 
eingebracht. Minimum? stellt somit das erste "echte" Macintosh- 
Programm in der Reihe der Beispiel-Programme dar. 


Die erweiterten Fähigkeiten von Minimum? sind: 


® Erzeugen eines Fensters 

« Verschieben des Fensters 

. Vergrößern / Verkleinern des Fensters 

® Zoom-Box-Unterstützung 

° Close-Box-Unterstützung 

® Zeichnen einer Grafik bei Update-Events 
® Behandlung von Activate-Events 








Das Programm Minimum? stellt eine Rahmenapplikation dar, 
auf der die nachfolgenden Beispiel-Programme aufbauen können. 
Es unterstützt bereits die wichtigsten Events des Event-Managers 
(MouseDown-, Update- und Activate-Events), die für die Fen- 
sterverwaltung eingesetzt werden. 


MouseDown-Events werden zunächst auf deren Ziel untersucht 
(Fenster verschieben, schließen oder zoomen), anschließend 
verzweigt das Programm in die entsprechenden Behandlungs- 
routinen. Diese Behandlungsroutinen verwenden dann die ent- 
sprechenden Window-Manager-Funktionen, um die vom Benutzer 
gewünschten Aktionen durchzuführen. 


Update-Events führen zum Aufruf einer Routine, die für das 
Zeichnen des Fensterinhaltes, der Grafik, verantwortlich ist. 


Activate-Events bewirken, daß eine Routine aufgerufen wird, die 
die Fensterelemente an den neuen Fensterzustand (aktiv oder 
inaktiv) anpaßt. 


Die folgende Illustration zeigt den internen Kontrollfluß bzw. 
die Funktionen der erweiterten Version von Minimum. 


_ [Sa Drawingllip ] 
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Zunächst wird im Hauptprogramm die Funktion Init_ToolBox 
aufgerufen. Diese Funktion initialisiert die benötigten ToolBox- 
Manager. Anschließend wird die Funktion Make_Window auf- 
gerufen, die dann ein leeres Fenster mit Hilfe des Window- 


Do_Ciose Window | 


Managers erzeugt. 

Danach begibt sich das Programm in die Main-Event-Loop und 
wartet auf einen Event. Liegt ein Event vor, so verzweigt es in 
die Event-Behandlungsroutine Do_Event. Diese Funktion ent- 
scheidet anhand der Art des Events, welche der Event-Behand- 
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Abb. 10-5 

Der Kontrollfiuß von 
MINIMUM2. 

Die Main-Event-Loop 
ruft die Event- 
Behandlungsroutine 
Do_Event auf, welche 
wiederum in speziali- 
siertere Behandlungs- 
routinen verzweigt, um 
letztendlich auf den 
Event zu reagieren. 
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lungsroutinen (Do_MouseDown, Do_Update oder Do_Activate) 
aufgerufen wird. 

Die Event-Behandlungsroutine Do_MouseDown entscheidet 
anhand der Mausklick-Koordinaten, was der Benutzer möchte 
und verzweigt wiederum in die eigentlichen Aktionsroutinen. 
Die Aktionsroutine Do_CloseWindow wird aufgerufen, wenn der 
Benutzer in die Close-Box (das Schließfeld) des Fensters geklickt 
hat. Do_CloseWindow ruft dann TrackGoA way (eine Window- 
Manager-Funktion) auf, welche das Close-Box-Feedback erzeugt 
(Close-Box ein-/ausschalten). Soll das Fenster geschlossen wer- 
den, so ruft Do_CloseWindow die Funktion DisposeWindow auf, 
um das Fenster zu schließen und den Speicherplatz freizugeben. 
Da bisher noch keine Menüs existieren, wird das Beenden des 
Programms durch das Schließen des Fensters erreicht. Wird das 
Fenster geschlossen, so setzt Do_CloseWindow das globale Boolean 
gQuit auf true, und das Programm terminiert. 

Die Aktionsroutine Do_GrowWindow wird von Do_MouseDown 
aufgerufen, wenn der Benutzer in die Grow-Box des Fensters 
geklickt hat, um das Fenster zu vergrößern oder zu verkleinern. 
Do_GrowWindow benutzt die Window-Manager-Funktionen 
GrowWindow und SizeWindow, um dies zu ermöglichen. 
Klickt der Benutzer in die Zoom-Box des Fensters, so wird die 
Funktion Do_ZoomWindow aufgerufen. Diese Funktion benutzt 
die Window-Manager-Funktionen TrackBox, um für das User- 
Interface des Zoomens (Close-Box ein/ausschalten) zu sorgen, 
bzw. die Funktion ZoomWindow, um das Fenster wirklich zu 
zoomen. 

Auch das Verschieben des Fensters ist möglich. In diesem Fall 
ruft Do_MouseDown die Aktionsroutine Do_DragWindow auf. 
Diese Funktion benutzt die Window-Manager-Funktion Drag- 
Window, um dem Benutzer das Verschieben des Fensters zu 
ermöglichen. 

Wenn die Event-Behandlungsroutine Do_Event einen Update- 
Event bekommt, so wird die Funktion Do_Update aufgerufen. 
Do_Update sorgt dafür, daß die Grow-Box gemalt wird und daß 
die Grafik gezeichnet wird. Zum Zeichnen der Grafik ruft 
Do_Update die Funktion Draw_Graphics auf, die den Kreis 
zeichnet. Damit Draw_Graphics nicht über die am Rand des 
Fensters gelegenen Bereiche für die (noch nicht vorhandenen) 
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Scrollbars zeichnet, ruft Do_Update vorher Set_DrawingClip auf. 
Diese Funktion berechnet und setzt eine Clipping-Region, die 
die äußeren Scrollbar-Bereiche ausklammert; Draw_Graphics 
braucht beim Zeichnen des Kreises nicht auf die Scrollbar-Bereiche 
zu achten, da die Clipping-Region ein Überzeichnen dieser Bereiche 
verhindert. 

Bei einem Activate-Event ruft die Funktion Do_Event die Event- 
Behandlungsroutine Do_Activate auf. Diese Funktion sorgt da- 
für, daß die Fensterelemente als aktiv bzw. inaktiv gekennzeich- 
net werden. Da das Beispiel-Programm bisher keine Scrollbars 
hat, wird nur die Grow-Box an den neuen Zustand des Fensters 
(aktiviert oder deaktiviert) angepaßt. 


Im Folgenden werden die einzelnen Routinen des Programms 
aufgelistet und analysiert. Der komplette Quelltext des Programms 
folgt am Schluß dieser Analyse. 


Das Hauptprogramm: 


: #include <Types.h> 

: #include <QuickDraw.h> 
: #include <Fonts.h> 

: #include <Windows.h> 

: #include <Events.h> 

: #include <ToolUtils.h> 


: WindowPtr gwindow; 
: EventRecord gEvent; 
: Boolean gGotEvent, gQuit; 


: void main (void) 


HHrHbbetrrHrHrHrH 
VONIAUBWND HOSE NAUM BWIN H 


Das Hauptprogramm 
{ beinhaltet die Main- 
Dealer Event-Loop. Liegt ein 
EI Io9I ER N; Event vor, dann wird die 
Make Window (); 
Seterädr (&qd.arrow); Event-Behandlungsrou- 
while (!gQuit) tine Do_Event aufgeru- 
20 { fen, welche für die 
21 gGotEvent = WaitNextEvent (everyEvent, Abarbeitung des Events 
&gEvent, 15, NULL); sorgt. 
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228 if (gGotEvent) 
23: Do Event (); 
24: } 

252 


In den Zeilen 1 bis 6 werden die üblichen Interface-Dateien zu 
den verwendeten Managern mit Hilfe von #include-Statements 
eingebunden. Neu ist hier die Einbindung der ToolUtils-Bibliothek, 
die einige nützliche Hilfsfunktionen beinhaltet. Minimum ver- 
wendet die Funktionen HiWord und LoWord dieser Bibliothek, 
die jeweils das Hi- bzw. das Lo-Word aus einem long extrahie- 
ren. 

Das Programm verwendet vier globale Variablen (gWindow, 
gEvent, gQuit und gGotEvent). 

Die Variable gWindow wird für die Verwaltung des Fensters 
verwendet. 

Der EventRecord gEvent beinhaltet jeweils den aktuellen Event. 
Die Event-Behandlungsroutinen greifen auf diese Variable zu, 
um auf einen Event zu reagieren. 

Der Boolean gGotEvent wird in der Main-Event-Loop verwen- 
det, um den Ergebniswert der Funktion WaitNextEvent aufzu- 
nehmen. 

Die globale Variable gQuit ist das Terminationskriterium des 
Programms. Wird sie irgendwo im Programm auf true gesetzt, 
so terminiert das Programm. 

Übrigens: Alle globalen Variablen sind durch ein kleines "g" am An- 
fang des Namens gekennzeichnet. Die selbstgeschriebenen Funktionen 
beinhalten einen "Underscore” ("_") im Namen, damit sie leichter von 
ToolBox-Routinen unterschieden werden können. 


In Zeile 15 wird zunächst das Terminationskriterium gQuit auf 
false gesetzt, so daß die Main-Event-Loop (Zeile 19 bis 25) laufen 
kann. 

In Zeile 16 wird die Initialisierungsroutine Init_ToolBox aufge- 
rufen. Diese Routine übernimmt die Initialisierung der Manager 
(QuickDraw, Fonts, Windows etc.). 

Die Funktion Make_Window übernimmt in Zeile 17 das Erzeu- 


. gen eines neuen Fensters. Sie entspricht dem Erzeugen eines 





Fensters im vorherigen Beispiel-Programm "Minimum" und wird 
daher hier nicht noch einmal erläutert. 

Zeile 18 sorgt mit einem Aufruf von SetCursor dafür, daß der 
Cursor auf den normalen Pfeil-Cursor gesetzt wird. Der Pfeil- 
Cursor istin den QuickDraw-Globals "qd" unter dem Feld "arrow" 
zu finden, daher wird hier die Adresse von qd.arrow übergeben. 
Das initiale Setzen des Cursors wird notwendig, da der Finder 
beim Starten der Applikation den Cursor auf den Watch-Cursor 
(Uhren-Cursor) setzt, um dem Benutzer eventuelle Wartezeiten 
anzudeuten. Dieser Cursor würde während der gesamten Laufzeit 
unseres Programms bestehen bleiben, wenn der Cursor nicht auf 
einen (von uns) definierten Zustand gesetzt würde. 

In Zeile 19 beginnt die Main-Event-Loop mit der Abfrage des 
Terminationskriteriums gQuit. Solange diese Variable auf false 
gesetzt ist, läuft die Main-Event-Loop. 

Zeile 20 fragt den Event-Manager mit Hilfe der Funktion 
WaitNextEvent nach einem neuen Event. Als Event-Maske wird 
everyEvent übergeben, was dafür sorgt, daß unser Programm 
alle Event-Arten aus der Event-Queue erhält. Liegt ein Event vor, 
so schreibt WaitNextEvent die Informationen über den Event in 
die globale Variable gEvent, deren Adresse bei dem Aufruf 
übergeben wird. Als "Wunsch-Hintergrundzeit" wird hier (vor- 
erst) eine Konstante übergeben. Diese von Apple vorgeschlage- 
ne konstante sleep-Zeit von 15 Ticks sorgt für eine flüssige Ab- 
arbeitung der Hintergrundprozesse, ohne den Programmablauf 
von Minimum zu stark zu behindern. In der derzeitigen Version 
des Programms wird die Fähigkeit des Event-Managers, das 
Programm mit einem Event davon zu informieren, daß der Maus- 
Cursor einen bestimmten Bereich verlassen hat, noch nicht ver- 
wendet. Daher wird anstelle des mouseRgn-Parameters der Wert 
NULL übergeben. 

Liegt ein Event vor, so wurde der Boolean gGotEvent von 
WaitNextEvent auf true gesetzt. In Zeile 23 wird in diesem Fall 
in die Event-Behandlungsroutine Do_Event verzweigt, welche 
dann je nach Event-Art in die entsprechenden Event-Behand- 
lungsroutinen weiterverzweigt. 
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Wenn die globale 
Variable gQuit irgendwo 
im Programm auf den 
Wert true gesetzt wird, 
dann terminiert das 
Programm. 

Die globale Variable 
gEvent beinhaltet den 
aktuellen Event. 
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Do_Event entscheidet 
anhand des Event-Typs, 
welche der spezialisier- 
ten Event-Behandlungs- 
routinen aufgerufen 
wird. 


Do_MouseDown 
reagiert auf einen 
MouseDown-Event, 
indem die Window- 
Manager-Funktion 
FindWindow aufgerufen 
wird. Anhand des 
Ergebniswertes dieser 
Funktion wird entschie- 
den, welche der 
Aktionsroutinen 

196 aufgerufen wird. 





Die Funktion Do_Event: 


1: void Do Event (void) 
2: 

3 switch (gEvent.what) 
4: { 

5 case mouseDown: 

6 Do _MouseDown (); 
7 break; 

8 

9: case updateEvt: 
10: Do_Update (); 
11: break; 
12: 
13: case activateEvt: 
14: Do Activate (); 
15: break; 
16: } 
17} 


Do_Event ist die"Schaltzentrale" der Event-Verwaltung. Hier wird 
in Zeile 3 anhand des Event-Types (gEvent.what) entschieden, 
welche Event-Behandlungsroutine aufgerufen wird. In der der- 
zeitigen Version unterstützt das Programm nur MouseDown-, 
Update- und Activate-Events. Entsprechend wird entweder die 
Funktion Do_MouseDown, Do_Update oder Do_Activate 
aufgerufen. 


Die Funktion Do_MouseDown: 


1: void Do MouseDown (void) 

2: { 

3: short part; 

4: windowPtr thewindow; 

5 

6 part = FindWindow (gEvent.where, 

&theWindow) ; 

7: switch (part) 

8: { 

95 case inDrag: 
10: Do _DragWindow (theWindow); 
11: break; 
12: 
13% case inZoomIn: 


14: case inZoomOut: 

155 Do _ZoomWindow (theWindow, part); 
16: break; 

1.73 

18: case inGrow: 

19: Do_GrowWindow (theWindow); 
20: break; 

21: 

22: case inGoAway: 

23: Do_CloseWindow (theWindow); 
24: break; \ 
25: } 

26: } 


Do_MouseDown ist die Schaltzentrale für MouseDown-Events. 
Die Funktion entscheidet anhand der Mausklick-Koordinaten, 
welche Aktionsroutine aufgerufen werden soll, die dann letzt- 
endlich auf den Event reagiert. 

Um herauszufinden, was der Benutzer möchte (Fenster ver- 
schieben, vergrößern/verkleinern etc...) wird in Zeile 6 die 
Funktion FindWindow verwendet. Dieser Window-Manager- 
Funktion werden die Koordinaten des Mausklicks (gEvent.where) 
übergeben, damit sie anhand dieser Koordinaten feststellen kann, 
in welchem Bereich des Bildschirmes (oder Fensters) der Maus- 
klick gelegen hat. Der Bildschirmbereich (inMenußBar, inDrag, 
inGrow etc...) wird von FindWindow als Ergebniswert geliefert 
und in der lokalen Variablen part gespeichert. Liegt der Mausklick 
in einem Fenster, so gibt FindWindow den WindowPtr dieses 
Fensters in unserer Variablen theWindow zurück. Die Funktion 
Do_MouseDown verwendet diesen WindowPtr, um bei dem 
Aufruf der Aktionsroutinen das Fenster, mit dem gearbeitet werden 
soll, zu spezifizieren. Auf diese Weise ist Do_MouseDown be- 
reits universell gestaltet; diese Funktion kann theoretisch auch 
mit mehreren Fenstern arbeiten, da sie sich nicht auf die globale 
Variable gWindow bezieht. 

Anhand des Ergebniswertes von FindWindow wird in Zeile 7 mit 
Hilfe der switch-Anweisung entschieden, welche Aktionsroutine 
aufgerufen werden soll. 

Hat der Benutzer in die Dragging-Region des Fensters geklickt, 
so wird in Zeile 10 die Aktionsroutine Do_DragWindow aufge- 
rufen. Ein Klick in die Zoom-Box des Fensters führt in Zeile 15 
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Do_DragWindow ruft 
DragWindow auf, damit 
das Fenster verschoben 

werden kann. 


Do_ZoomWindow läßt 
den Benutzer die Zoom- 
Box des Fensters 
betätigen und sorgt 
dafür, daß das Fenster 
gezoomt wird. 


zum Aufruf von Do_ZoomWindow. Bei diesem Aufruf von 
Do_ZoomWindow muß neben dem WindowPtr theWindow noch 
der Ergebniswert von FindWindow (part) übergeben werden, da 
Do_ZoomWindow unterschiedlich reagieren muß, je nachdem 
ob das Fenster vergrößert (inZoomOut) oder verkleinert wer- 
den.soll (inZoomIn). 

Die Funktion Do_MouseDown verzweigt in Zeile 19 in die 
Aktionsroutine Do_GrowWindow, wenn der Benutzer in die 
Grow-Region des Fensters geklickt hat, um das Fenster per Hand 
(per Maus) zu vergrößern bzw. zu verkleinern. 

In Zeile 23 wird die Funktion Do_CloseWindow aufgerufen, wenn 
der Benutzer in die Close-Box des Fensters geklickt hat. 


Die Funktion Do_DragWindow: 


1: void Do _DragWindow (WindowPtr theWindow) 

2: 4{ 

3% DragWindow (theWindow, qEvent.where, 
&qd.screenBits.bounds); 


Do_DragWindow ermöglicht in Zeile3 mit Hilfe des DragWindow- 
Aufrufs das Verschieben des Fensters. Der Parameter theWindow 
spezifiziert bei dem Aufruf von DragWindow das zu verschie- 
bende Fenster. Die Koordinaten des Mausklicks werden durch 
gEvent.where übergeben, die Begrenzung für das Verschieben 
des Fensters ist das umschließende Rechteck aller Monitore 
(qd.screenBits.bounds). 

Mit dem Aufruf von DragWindow ist das Ende der Event-Be- 
handlungskette erreicht. Das Programm kehrt in die Main-Event- 
Loop zurück, um auf weitere Events zu warten bzw. zu reagieren. 


Die Funktion Do_ZoomWindow: 


1: void Do_ZoomWindow (WindowPtr theWindow, 
short partCode) 


2:4 

3% if (TrackBox (theWindow, gEvent.where, 
partCode) ) 

4: ZoomWindow (theWindow, partCode, true); 

5: } 





Do_ZoomWindow wird bei einem Klick in die Zoom-Box des 
Fensters von Do_MouseDown aufgerufen. Dieser Funktion werden 
dabei zwei Parameter übergeben: 

1. Das Fenster, welches "gezoomt" werden soll. 

2. Ob das Fenster an die Bildschirmgröße angepaßt (partCode = 
inZoomOut) oder wieder auf die ursprüngliche Größe zurück- 
gebracht werden soll (partCode = inZoomIn). 

Diese beiden Parameter werden an die Funktion TrackBox 
übergeben, welche dann den User-Interface-Teil des Zoomens 
übernimmt. Diese Funktion verfolgt dieMausposition und zeichnet 
entweder eine gedrückte oder nichtgedrückte Zoom-Box. Wenn 
der Benutzer das Fenster zoomen möchte (er hat die Maustaste 
losgelassen, während die Mausposition innerhalb der Zoom-Box 
war), so gibt TrackBox den Wert true zurück, und es wird in Zeile 
4 ZoomWindow aufgerufen. 

ZoomWindow verlangt (wie TrackBox) die Spezifikation des zu 
zoomenden Fensters, sowie die Richtung (inZoomIn oder 
inZoomOut). Der letzte Parameter (true) spezifiziert, daß das 
Fenster, wenn es noch nicht über allen anderen gelegen hat, nach 
vorne geholt wird. Dieser Parameter macht eigentlich nur dann 
Sinn, wenn das Fenster durch die Auswahl eines Menüpunktes 
gezoomt wird, und es eventuell noch nicht im Vordergrund liegt. 
Hier wird einfach true übergeben, obwohl das Fenster sowieso 
schon über allen anderen liegt. 

Wie Do_DragWindow ist auch Do_ZoomWindow ein Ende der 
Event-Behandlungsverzweigung. Das Programm kehrt in die 
Main-Event-Loop zurück, um auf die nächsten Events zu warten. 


Die Funktion Do_GrowWindow: 


1: void Do _GrowWindow (WindowPtr theWindow) 
2: { 
3% long newSize; 

4: short newWidth, newHeight; 
5% Rect minMaxSize; 
6 
7 
8 
9 


minMaxSize.top = 80; 
minMaxSize.left = 160; 
minMaxSize.right = 
qd.screenBits.bounds.right; 
10: minMaxSize.bottom = 
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Do_GrowWindow 
ermöglicht es dem 
Benutzer, das Fenster zu 
vergrößern. Die 
maximale Fenstergröße 
entspricht dabei dem 
umschließenden 
Rechteck aller Monitore. 
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qd.screenBits.bounds.bottom; 


11: 

12: newSize = GrowWindow (theWindow, 
gEvent.where, &minMaxSize); 

13: if (newSize != 0) 

14: { 

15: newWwidth = LoWord (newSize); 

16: newHeight = HiWord (newSize); 

14: 

18: SizeWindow (theWindow, newWidth, 

newHeight, true); 

19: InvalRect (&theWindow->portRect); 

20: } 

21: } 


Do_GrowWindow wird aufgerufen, wenn der Benutzer in die 
Grow-Box des Fensters geklickt hat. Das Fenster, welches zu 
vergrößern bzw. zu verkleinern ist, wird durch den Parameter 
theWindow spezifiziert. 

Zunächst wird in den Zeilen 7 bis 11 dieminimale bzw. maximale 
Fenstergröße, die der Benutzer einstellen kann, ausgerechnet. Diese 
"Window-Bounds" werden im Rect minMaxSize verwaltet und 
dienen dem Aufruf von GrowWindow in Zeile 12. Die minimale 
Fenstergröße wird in Zeile7 und 8 in die Felder top bzw. left des 
Rects minMaxSize geschrieben. Der Benutzer kann das Fenster 
also nicht kleiner als 80 mal 160 Punkte machen. In Zeile 9 und 
10 wird die maximale Fenstergröße berechnet. Sie entspricht dem 
right- bzw. bottom-Feld des alle Bildschirme umschließenden 
Rechtecks qd.screenBits.bounds. 

Diese minimale bzw. maximale Fenstergröße wird in Zeile 12 an 
die Funktion GrowWindow übergeben. GrowWindow über- 
nimmt die Kontrolle und verfolgt die Mausposition. Während- 
dessen zeichnet GrowWindow das umschließende Rechteck der 
neuen Fenstergröße, so daß der Benutzer sehen kann, wie groß 
das Fenster wird, wenn er die Maustaste losläßt. Bei dem Aufruf 
von GrowWindow wird weiterhin das Fenster, dessen Größe 
verändert werden soll, durch den Parameter theWindow spezi- 
fiziert. Die Startposition des Mausklicks (gEvent.where) wird als 
letzter Parameter übergeben. 

GrowWindow gibt in dem Ergebniswert der Funktion die vom 
Benutzer gewünschte neue Größe des Fensters zurück. Die neue 


Größe des Fensters ist in dem long verschlüsselt enthalten: Das 
Hi-Word des longs enthält die gewünschte neue Höhe des Fen- 
sters, das Lo-Word die neue Breite. Wenn der Benutzer die Größe 
des Fensters nicht verändern möchte, so gibt GrowWindow den 
Wert 0 zurück. 

In Zeile 13 wird abgefragt, ob das Fenster vergrößert werden 
soll, anschließend wird für die Vergrößerung des Fensters gesorgt. 
Zunächst muß in Zeile 15 bzw. 16 der "verschlüsselte" Ergebnis- 
wert von GrowWindow "dechiffriert" werden. Dies geschieht mit 
Hilfe der ToolUtils-Funktion HiWord bzw. LoWord. Diese 
Funktionen extrahieren das entsprechende Word aus dem über- 
gebenen long. 

In Zeile 18 wird schließlich das Fenster vergrößert. Dies geschieht, 
indem die Window-Manager-Funktion SizeWindow aufgerufen 
wird. Bei diesem Aufruf wird das Fenster durch den Parameter 
theWindow, dieneue Höhe durch newHeight und die Breite durch 
newWidth spezifiziert. Der letzte Parameter (true) gibt an, daß 
bei eventuell freigelegten Flächen ein Update-Event an das Pro- 
gramm geschickt werden soll. 

Zeile 19 stellt eine Vereinfachung des Fenstervergrößerungs- 
Prozesses dar. Wenn das Fenster vergrößert oder verkleinert wurde, 
so wird mit Hilfe der Window-Manager-Funktion InvalRect der 
gesamte Fensterinhalt als ungültig markiert. Das Programm be- 
kommt somit einen Update-Event für das gesamte Fenster, und 
der gesamte Fensterinhalt wird neu gezeichnet. Diese Technik 
wird von vielen Macintosh-Programmen verwendet, um den 
Prozeß des Fenstervergrößerns zu vereinfachen. 


Die Funktion Do_CloseWindow: 


: void Do_CloseWindow (WindowPtr theWindow) 
at 
if (TrackGoAway (theWindow,gEvent.where)) 


1 
2 
3 
4: { 

9% DisposeWindow (theWindow); 
6 . 

7 

8 

9 


gQuit = true; 


10.7 MINIMUM2 





Do_CloseWindow 
reagiert auf einen Klick 
in das Schließfeld des 
Fensters, indem die 
Funktion TrackGoAway 
aufgerufen wird. Wenn 
der Benutzer das 
Fenster schließen will, 
wird das Terminations- 
kriterium gQuit gesetzt. 


201 


Kapitel 10 


Events 





202 


Do_Update reagiert auf 
einen Update-Event, 
indem die Clipping- 
Region auf den 
neuzuzeichnenden 
Bereich gesetzt und 
anschließend die 
gesamte Grafik neu 
gezeichnet wird. 


Do_CloseWindow wird aufgerufen, wenn der Benutzer in die 
Go-Away-Box des Fensters klickt. Das Fenster, welches geschlossen 
werden soll, wird durch den Parameter theWindow spezifiziert. 
Zunächst ruft Do_CloseWindow die Window-Manager-Funkti- 
on TrackGoAway auf. TrackGoAway übernimmt (wie Track- 
Box) die Kontrolle und verfolgt die Mausposition, um die ge- 
drückte bzw. nichtgedrückte Go-Away-Box zu zeichnen. 

Wenn der Benutzer das Fenster schließen möchte, so gibt 
TrackGoAway true zurück. In diesem Fall wird das Fenster in 
Zeile 5 mit Hilfe von DisposeWindow geschlossen und der as- 
soziierte Speicherplatz freigegeben. 

Da Minimum2 noch keine Menüverwaltung besitzt, ist der Aus- 
stieg aus dem Programm mit Hilfe des üblichen "Beenden"- 
Menüpunktes aus dem "Ablage"-Menü nicht möglich. Als "Quick- 
And-Dirty"-Lösung wurde hier das Verlassen des Programms 
über die Close-Box des Fensters gewählt. Daher wird in Zeile 7 
das globale Terminationskriterium gQuit auf true gesetzt. Das 
Programm verläßt dann die Main-Event-Loop und terminiert. 


Die Funktion Do_Update: 


1: void Do Update (void) 

2 u 

3: windowPtr theWindow; 

4 

SH thewindow = (WindowPtr) gEvent.message; 
6: BeginUpdate (theWindow) ; 

7: 

8 ClipRect (&theWindow->portRect); 
9 EraseRect (&theWindow->portRect); 
10 DrawGrowIcon (theWindow) ; 
11: 
12: Set_DrawingClip (theWindow); 

13: Draw Graphics (theWindow); 

14: 
15: EndUpdate (theWindow) ; 
16: } 


Do_Update steht auf der gleichen Ebene wie Do_MouseDown. 
Diese Funktion wird von Do_Event aufgerufen, wenn ein Update- 
Event aufgetreten ist. 


Bei einem Update-Event befindet sich der WindowPtr, der das 
Fenster spezifiziert, welches neu gezeichnet werden soll, in dem 
Universalfeld des EventRecords (message). Dieses Feld wird (der 


Übersichtlichkeit halber) in Zeile 5 in die lokale Variable the- 


Window überführt. Damit der Compiler die Zuweisung von 
message (long) an theWindow (WindowPtr) zuläßt, wird die 
Technik des Type-Castings verwendet. Im folgenden Verlauf der 
Funktion wird theWindow verwendet, um das Fenster zu spe- 
zifizieren. 

Zeile 6 startet die Abarbeitung des Update-Events mit dem Auf- 
ruf von BeginUpdate. Diese Funktion schränkt die Visible-Region 
der Zeichenumgebung temporär auf den neuzuzeichnenden 
Bereich ein. Dadurch können nachfolgende Zeichenbefehle nur 
in dem neuzuzeichnenden Bereich malen. Der Aufruf von End- 
Update in Zeile 15 beendet den Update-Prozeß und setzt die 
Visible-Region der Zeichenumgebung wieder auf den ur- 
sprünglichen Bereich. 

Die Zeilen 8bis 13 sorgen für das Neuzeichnen des Fensterinhaltes. 
Zunächst wird in Zeile 8 dafür gesorgt, daß die Clipping-Region 
auf den gesamten Fensterinhalt gesetzt wird, indem die Funk- 
tion ClipRect aufgerufen wird. Dieser Funktion wird das um- 
schließende Rechteck der Zeichenumgebung (die Adresse von 
theWindow->portRect) übergeben, dadurch entspricht die 
Clipping-Region dem gesamten inneren Bereich des Fensters. 
In Zeile 9 wird der gesamte Fensterinhalt mit einem Aufruf von 
EraseRect gelöscht. Da die Visible-Region der Zeichenumgebung 
von BeginUpdate auf den neuzuzeichnenden Bereich gesetzt 
wurde, löscht dieser Befehl nur die neuzuzeichnenden Bereiche. 
Die erhaltenen Bereiche des Fensters werden nicht gelöscht. 
Dadurch verhält sich das Programm bei einem Update-Event 
äußerst elegant: Nur die Teile des Fensterinhaltes werden neu 
gezeichnet, die auch wirklich neugezeichnet werden müssen. Diese 
Technik bewirkt einen "ruhigen" und schnellen Fensteraufbau. 
Zeile 10 sorgt mit dem Aufruf von DrawGrowlcon dafür, daß das 
Grow-Icon bzw. die für Scrollbars freigehaltenen Bereiche ge- 
zeichnet werden. 

Zeile 12 setzt die Clipping-Region auf den inneren Bereich des 
Fensters abzüglich des Bereiches, der für die Scrollbars reser- 
viert ist (rechts und unten jeweils 15 Punkte). Daher braucht bei 
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Abb. 10-6 

Die Illustration zeigt, wie 
die Grafik (Kreis) von 
der Clipping-Region 
beschnitten wird. Die 
Bereiche, die für die 
Scrollbars reserviert 

. sind, werden nicht 
überzeichnet. 


Set_DrawingClip 
schränkt den Zeichen- 
bereich ein, so daß die 

Grafik nicht über die für 
die Scrollbars reservier- 
ten Bereiche zeichnet. 
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nachfolgenden QuickDraw-Befehlen nicht darauf geachtet zu 
werden, ob sie über die Scrollbars zeichnen. Die Beschränkung 
des Zeichenbereiches besteht damit aus der auf den Update-Bereich 
gesetzten Visible-Region und dem inneren Bereich des Fenster 
minus den für die Scrollbars reservierten Bereich. 


rer 








In Zeile 13 wird dann die Funktion Draw_Graphics aufgerufen, 
die für das Zeichnen der Grafik (des Kreises) verantwortlich ist. 
In Zeile 15 wird der Update-Prozeß durch den Aufruf von 
EndUpdate abgeschlossen. EndUpdate setzt die Visible-Region 
der Zeichenumgebung auf den ursprünglichen Bereich zurück. 


Die Funktion Set_DrawingClip: 


void Set DrawingClip (WindowPtr theWindow) 
2, 
: Rect drawableRect; 


drawableRect.right -= 15; 
drawableRect .bottom -= 15; 


1: 
2 
3 
4: 
5% drawableRect = theWindow->portRect; 
6 . 
7a 
8: ClipRect (&drawableRect); 

9: 


} 


Set_DrawingClip berechnet in den Zeile 5 bis 7 das Rechteck, in 
dem die Grafik gezeichnet werden darf. Dazu wird in Zeile 5 
zunächst das umschließende Rechteck der Zeichenumgebung 
(GrafPort) in die lokale Variable drawableRect geschrieben. In den 


Zeilen 6 bzw. 7 werden von dem Rechteck jeweils 15 Punkte unten 
und rechts abgezogen, um den Bereich, der für die Scrollbars 
reserviert ist, auszusparen. 

In Zeile 8 wird schließlich die QuickDraw-Funktion ClipRect dazu 
verwendet, den Zeichenbereich auf das ausgerechnete Rechteck 
zu beschränken. 


Die Funktion Draw_Graphics: 


void Draw_Graphics (WindowPtr /*theWindow*/) 


Rect ovalRect; 


SetRect (&ovalRect, 0, 0, 200, 200); 
FrameOval (&ovalRect); 


als= 
2 
3 
4: 
5 
6 
7:2} 

Draw_Graphics ist für das Neuzeichnen der Grafik verantwort- 
lich. 

In Zeile 6 wird die QuickDraw-Funktion FrameOval verwendet, 
um das Oval zu zeichnen. 


Die Funktion Do_Activate: 


void Do Activate (void) 


{ 
windowPtr theWindow; 


thewindow = (WindowPtr) gEvent .message; 


ClipRect (&theWindow->portRect); 
DrawGrowIcon (theWindow) ; 


E: 
2 
3 
4 
5% 
6: 
7 . 
8 
9 Set DrawingClip (theWindow); 
0 


2) 


Do_Activate wird von der Event-Behandlungsroutine Do_Event 
aufgerufen, wenn ein Activate-Event vorliegt. In diesem Fall soll 
sich das Programm darum kümmern, daß die Fensterelemente 
als aktiv bzw. inaktiv gekennzeichnet werden. Da bisher keine 
Scrollbars vorhanden sind, braucht sich diese Funktion nur darum 
zu kümmern, die Grow-Box an den jeweiligen Zustand des Fensters 


10.7 MINIMUM2 





Draw_Graphics zeichnet 
die Grafik (das Oval). 


Do_Activate reagiert auf 
einen Activate-Event, 
indem das Grow-Icon 
entsprechend des neuen 
Aktivierungszustandes 
des Fensters (aktiv oder 
inaktiv) gezeichnet wird. 
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Die #include- 
Statements binden die 
Interface-Dateien der 
benötigten Manager in 
den Quelltext ein. 


Die Deklaration der 
globalen Variablen. 


anzupassen. Wenn das Fenster aktiv ist, soll die Grow-Box sicht- 
bar sein, im inaktiven Zustand hingegen unsichtbar. 

Bei einem Activate-Event spezifiziert der Universalparameter 
message des EventRecords, welches Fenster aktiviert bzw. de- 
aktiviert werden soll. Da gEvent.message ein long ist, wird der 
Wert dieses Feldes in Zeile 5 mit Hilfe von Type-Casting in einen 
WindowPir verwandelt und in die lokale Variable theWindow 
geschrieben. Auf diese Weise braucht in den Zeilen 7 bis 9 kein 
Type-Casting verwendet werden, was die Lesbarkeit des Quell- 
textes erhöht. 

Die Implementierung der "Human Interface Guidelines" in bezug 
auf Activate-Events wird durch den Aufruf von DrawGrowlcon 
in Zeile 8 durchgeführt. DrawGrowlcon paßt die Grow-Box au- 
tomatisch an den aktuellen Zustand des Fensters an (aktiv oder 
inaktiv), daher muß nicht zwischen Activate- und DeActivate- 
Events unterschieden werden. Damit die Clipping-Region des 
Fensters so gesetzt ist, daß DrawGrowlcon zeichnen kann, wird 
in Zeile 7 die Clipping-Region durch den Aufruf von ClipRect auf 
den gesamten Fensterbereich erweitert. Der Aufruf von 
Set_DrawingClip in Zeile 9 setzt die Clipping-Region wieder 
auf den Bereich zurück, in dem die Grafik gezeichnet werden 
darf. 


Das folgende Listing ist der komplette Quelltext von Minimum?: 


: #include <Types.h> 

: #include <QuickDraw.h> 
: #include <Fonts.h> 

: #include <Windows.h> 

: #include <Events.h> 

: #include <ToolUtils.h> 


oo v0» PWPN HM 


10: WindowPtr gWindow; 
11: EventRecord gEvent; 
12: Boolean gGotEvent, gQuit; 


16: 
17: 
18: 
19: 
20: 
21% 
22: 
2.38 
24: 
25: 
26: 
27: 


28: 
29: 
30% 
31: 
32: 
33: 
34: 
39# 


36: 
37: 
38: 
39: 
40: 
41: 
42: 
43: 


44: 
45: 
46: 
47: 
48: 
49: 
50: 
51: 
52: 
33% 
54: 
55: 
56: 
9.158 


void Init_ToolBox (void) 

{ 
InitGraf ((Ptr) &qd.thePort); 
InitFonts (); 
InitWindows (); 


void Make Window (void) 
{ 
qWindow = GetNewWindow (128, NULL, 
(windowPtr) -1); 
SetPort (gWindow); 


void Do DragWindow (WindowPtr theWindow) 
{ 
DragWindow (theWindow, gEvent..where, 
&qd.screenBits.bounds); 


void Do_ZoomWindow (WindowPtr theWindow, 
short partCode) 
{ 
if (TrackBox (theWindow, gEvent.where, 
partCode)) 


ZoomWindow (theWindow, partCode, true); 


void Do _GrowWindow (WindowPtr theWindow) 
{ 

long newSize; 

short newWidth, newHeight; 

Rect minMaxSize; 


minMaxSize.top = 80; 

minMaxSize.left = 160; 

minMaxSize.right = 
qd.screenBits.bounds.right; 


10.7 MINIMUM2 





Init_TooIBox initialisiert 
die benötigten Manager. 


Make_Window erzeugt 
ein neues Fenster. 


Do_DragWindow 
ermöglicht das 
Verschieben des 
Fensters. 


Do_ZoomWindow 
erlaubt dem Benutzer, 
das Fenster zu zoomen. 


Do_GrowWindow 
ermöglicht es dem 
Benutzer, das Fenster zu 
vergrößern. Die 
maximale Fenstergröße 
entspricht dabei dem 
umschließenden 
Rechteck aller Monitore. 
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Wenn der Benutzer eine 
gültige Fenstergröße 
ausgewählt hat, wird 

das Fenster vergrößert. 


Do_CloseWindow setzt 
das Terminations- 
kriterium, wenn der 
Benutzer das Fenster 
schließen will. 


Do_MouseDown 
entscheidet anhand des 
Ergebniswertes von 
FindWindow, welche 
Aktionsroutine aufgeru- 
fen wird. 


58: minMaxSize.bottom = 
ad.screenBits.bounds.bottom; 

59% 

60: newSize = GrowWindow (theWindow, 
gEvent.where, &minMaxSize); 

61: if (newSize != 0) 

62: { 

63: newWidth = LoWord (newSize); 

64: newHeight = HiWord (newSize); 

65: 

66: SizeWindow (theWindow, newWidth, 

newHeight, true); 

67 InvalRect (&thewWindow->portRect); 

68: } 

69: } 

70: 

I18-L# #738 -55 523 SE 

12: 

73: void Do _CloseWindow (WindowPtr theWindow) 

74: { 

75 if (TrackGoAway (theWindow,gEvent.where) ) 

76: { 

13 DisposeWindow (theWindow) ; 

78: 

79: gQuit = true; 

80:- } 

81: } 

82: 

B3E Nr ES TE SEE DSH 

84: 

85: void Do _MouseDown (void) 

86: { 

87: short part; 

88: windowPtr thewWindow; 

89: 

90: part = FindWindow (gEvent.where, 
&theWindow) ; 

91: switch (part) 

92: { 

93: case inDrag: 

94: Do_DragWindow (theWindow) ; 

95: break; 

96: 

97: case inZoomIn: 

98: case inZoomOut: 

99: Do ZoomWindow (theWindow, part); 





break; 


case inGrow: 
Do_GrowWindow (theWindow); 
break; 


case inGoAway: 
Do_CloseWindow (theWindow); 
break; 


void Draw Graphics ( 
WindowPtr /*theWindow*/) 
{ 
Rect ovalRect; 


SetRect (&ovalRect, 0, 0, 200, 200); 


FrameOval (&ovalRect); 


void Set DrawingClip ( 
WindowPtr theWindow) 


{ 
Rect drawablerRect; 


drawableRect = theWindow->portRect; 


drawableRect.right -= 15; 
drawableRect.bottom -= 15; 
ClipRect (&drawableRect); 


void Do Update (void) 
{ 


WindowPtr theWindow; 


theWindow = (WindowPtr) gEvent..message; 


BeginUpdate (theWindow) ; 


ClipRect (&thewWindow->portRect); 
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Draw_Graphics ist für 
das Neuzeichnen der 
Grafik bei einem 
Update-Event zuständig. 


Set_DrawingClip 
beschränkt den 
Zeichenbereich, so daß 
die Grafik nicht den für 
die Scrollbars reservier- 
ten Bereich übermalt. 


Do_Update reagiert auf 
einen Update-Event, 
indem der Zeichen- 
bereich auf den 
neuzuzeichnenden 
Bereich beschränkt 
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Nachdem der Zeichen- 
bereich eingeschränkt 
ist, sorgt Do_Update 
dafür, daß die gesamte 
Grafik gezeichnet wird. 


Do_Activate reagiert auf 
einen Activate-Event, 
indem das Grow-Icon an 
den neuen Aktivierungs- 
zustand des Fensters 
(aktiv oder inaktiv) 
angepaßt wird. 


Do_Event entscheidet 
anhand des Event-Typs, 
welche Event- 
Behandlungsroutine 
aufgerufen wird, 


EraseRect (&theWindow->portRect); 
DrawGrowIcon (theWindow) ; 


Set _DrawingClip (theWindow); 
Draw Graphics (theWindow); 


EndUpdate (theWindow) ; 


void Do Activate (void) 


{ 


windowPtr theWindow; 
thewWindow = (WindowPtr) gEvent .message; 
ClipRect (&theWindow->portRect); 


DrawGrowIcon (theWindow) ; 
Set_DrawingClip (theWindow); 


void Do Event (void) 


{ 


switch (gEvent.what) 
{ 
case mouseDown: 
Do_MouseDown (); 
break; 


case updateEvt: 
Do_Update (); 
break; 


case activatekvt: 


Do Activate (); 
break; 


188: 
189: 
190: 
191: 
192: 
193: 
194: 
195: 
196: 


197: 
198: 
199: 
200: 


void main (void) 


{ 


gQuit = false; 

Init_ToolBox (); 
Make Window (); 
SetCursor (&qd.arrow); 
while (!gQuit) 


{ 


gGotEvent = WaitNextEvent ( 


everyEvent, 
if (gGotEvent) 
Do Event (); 


&gEvent, 


15, 


NULL); 


10.7 MINIMUM2 





Das Hauptprogramm 
beinhaltet die Main- 
Event-Loop, welche 
solange läuft, bis der 
Benutzer das Fenster 
schließt und dadurch 
das Terminations- 
kriterium gesetzt wird. 
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Dieses Kapitel enthält eine Einführung in die Menütechnik des 
Macintosh. Zunächst werden die "Human Interface Guidelines" 
für die Erstellung von Menüs erläutert. Eine Beschreibung der 
wichtigsten Menu-Manager-Routinen bzw. Datenstrukturen folgt 
dann im zweiten Teil dieses Kapitels. Der dritte Teil beschäftigt 
sich mit der Demonstration der Menüverwaltung anhand einer 
erweiterten Version von MINIMUM. 

Die Menüs sind ein wichtiger Teil der Macintosh-Benutzer- 
schnittstelle, da viele Programmfunktionen durch eine Menü- 
auswahl zu erreichen sind. Die Menüzeile ist der ständige Be- 
gleiter des Benutzers, sie stellt den Befehlsumfang eines jeden 
Macintosh-Programms dar. 

Bei der Strukturierung der Menüs ist unbedingt auf die gültigen 
Menü-Standards zu achten. So ist neben dem "Apple"-Menü 
(welches bei allen Applikationen gleich aussieht) eine eindeuti- 
ge Standardisierung des "Ablage"- und des "Bearbeiten"-Menüs 
eine wichtige Voraussetzung für ein benutzerfreundliches Pro- 
gramm. 

Im "Apple"-Menü sollte neben dem "Über das Programm...."-Menü 
höchstens noch ein "Hilfe..."-Menüpunkt existieren, wobei die 
applikationseigenen Menüpunkte durch eine gepunktete Linie 
von den "Apple"-Menü-Einträgen getrennt sein sollten. 

Das "Ablage"-Menü enthält Menübefehle, die sich mit der Er- 
zeugung, dem Abspeichern oder dem Exportieren von Doku- 
menten beschäftigen. Die Reihenfolge und Namensgebung die- 
ser Standard-Menüeinträge ist sehr wichtig für das Macintosh- 
Gesamtsystem. Dadurch, daß sich alle Macintosh-Applikationen 
an die Reihenfolge und Namensgebung dieser Menüpunkte halten, 
ist es dem Benutzer ohne Schwierigkeiten möglich, mit vielen 
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Abb. 11-1 

Ein standardisiertes und 
ein erweitertes "Ablage'- 
Menü. 






Widerrufen %2 








Ausschneiden &#H 
Kopieren sc 
Einsetzen RU 
Löschen 


Zwischenablage 


Abb. 11-2 

Das standardisierte 
"Bearbeiten'-Menü einer 
Macintosh-Applikation. 





Programmen zu arbeiten, ohne sich jedesmal an die Eigenheiten 
des jeweiligen Programms erinnern zu müssen. 

In Abb. 11-1 wird ein standardisiertes und ein erweitertes "Abla- 
ge"-Menü gezeigt. Die Reihenfolge der Standard-Menüeinträge 
bleibt gleich. 





Neu Neu #N 
Offnen... Offnen... %0 
| Schließen Schließen SW 
Sichern Sichern 6.27 


Sichern unter... 


Sichern unter... 


Letzte Version 
Seitenformat... 
Drucken... &%P Zwischenergebnis sichern 


Zwischenergebnis löschen 





*Q 


Beenden 
Seitenformat... 
Drucken... 
Bereich drucken... 


*P 





Beenden 





Das "Bearbeiten"-Menü, welches sich mit dem Ausschneiden, 
Einsetzen etc... beschäftigt, ist noch weitaus standardisierter als 
das "Ablage"-Menü. Es ist sozusagen "Vorschrift", dieMenüpunkte 
"Widerrufen", "Ausschneiden", "Kopieren", "Einfügen" und 
"Löschen" exakt in dieser Reihenfolge und Namensgebung im 
"Bearbeiten"-Menü darzustellen. Zusätzliche Menüpunkte soll- 
ten durch eine gepunktete Linie von den standardisierten 
Menüpunkten getrennt werden. 


1 Der Menu-Manager 
Der Menu-Manager ist für die Erzeugung und Verwaltung der 
Menüs zuständig. Er bietet viele Variationsmöglichkeiten für die 
Darstellung der Menüs bzw. ihrer Menüpunkte. Die wichtigsten 
Variationsmöglichkeiten sind: 


1. Das "Disablen" eines Menüpunktes. 
Der Menüpunkt kann nicht ausgewählt werden (er wird grau 
gezeichnet), bleibt jedoch sichtbar. 


2. Das "Checken" eines Menüpunktes. 

Der Menüpunkt bekommt ein Häkchen. Diese Technik wird oft 
verwendet, um einem Menü eine Ein- und Ausschaltfunktion 
für eine Option zu geben. Viele Textverarbeitungsprogramme 
verwenden beispielsweise ein solches Häkchen, um die aktuell 
eingestellten Schriftschnitte in einem Menü zu kennzeichnen. 


3. Die Verwendung von Menükurzbefehlen. 

Wenn der Benutzer eine Taste in Kombination mit der Befehls- 
taste drückt, so entspricht dies der Auswahl des Menüpunktes. 
Menükurzbefehle erlauben erfahrenen Benutzern, immer wie- 
derkehrende Arbeitsschritte durch diese "Short-Cuts" zu be- 
schleunigen. 


Der Menu-Manager setzt bei der Erzeugung der Menüs auf 
Resource-Templates auf. Diese 'MENU'-Resources enthalten die 
Beschreibung eines Menüs mit seinen Unterpunkten. In diesen 
Beschreibungen sind sowohl die Menü-Texte als auch die Menü- 
kurzbefehle und einige weitere Informationen enthalten. 'MENU'- 
Resources können mit Hilfe von ResEdit erzeugt und auch loka- 
lisiert werden. ResEdit bietet hierfür einen Menu-Editor, der sich 
mit dem Anlegen und Verändern von Menüs beschäftigt. 
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Die Installation eines neuen Menüs erfolgt, indem eine 'MENU'- 
Resource geladen und auf der Basis dieses Menü-Templates mit 
Hilfe der entsprechenden Menu-Manager-Funktion ein neues 
Menü erzeugt wird. 

Die Verwaltung von Menüs gliedert sich an die Main-Event-Loop 
eines Macintosh-Programms an. Wenn der Benutzer in die 
Menüleiste klickt, so reagiert das Programm, indem es zunächst 
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Abb. 11-3 

Die verschiedenen 
Variationsmöglichkeiten 
der Darstellung von 
Menüpunkten. 


Abb. 11-4 

Die Illustration zeigt den 
Menu-Editor von 
ResEdit, mit dem 
Menüpunkte angelegt, 
gelöscht oder verändert 
werden können. 
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Eine'MENU'-Resource 
beschreibt ein Menü mit 
seinen Menüpunkten. Zu 
jedem Menüpunkt 
können bestimmte 
Optionen angegeben 
werden (z.B., ob der 
Menüpunkt einen 
Menükurzbefehl hat). 


Die Menu-ID eines 
Menüs wird nach der 
Installation des Menüs 
verwendet, um das 
Menü zu identifizieren. 
Sie ist unabhängig von 
der Resource-ID der 


'MENU'-Resource. 
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die Kontrolle an den Menu-Manager abgibt. Der Menu-Mana- 
ger übernimmt den User-Interface-Teil dieser Aktion. Er klappt 
die Menüs herunter und läßt den Benutzer einen Menüpunkt 
auswählen. Anschließend ruft das Programm die entsprechenden 
Aktionsroutinen auf, welche dann auf die Menüauswahl reagie- 
ren. 


11.2 Routinen und Datenstrukturen 

Der Menu-Manager basiert (wie beschrieben) auf 'MENU'-Re- 
sources. Eine solche Menu-Resource beschreibt ein komplettes 
Menü mit seinen Menüpunkten und den Attributen, die zu den 
Menüpunkten gehören. 

Die folgende MENU'-Resource beschreibt die (verkürzte Version) 
eines "Ablage"-Menüs: 


1: resource 'MENU' (129) { 

2 129, 

3 textMenuProc, 

4: allEnabled, 

I: enabled, 

6: "Ablage", 

7 { 

8: "Neu", nolcon, "N", noMark, plain, 
9: "-", nolcon, noKey, noMark, plain, 
10: "Beenden", nolcon, "Q", noMark, plain 
16: } 
17247 


In Zeile 1 beginnt der normale Resource-Header. Hier wird 
festgelegt, daß eine MENU'-Resource mit der ID 129 definiert 
werden soll. 

Das erste 'MENU'-Resource-Description-Statement in Zeile 2 
vergibt die Menu-ID für das Menü. Diese Menu-ID wird vom 
Menu-Manager nach der Installation des Menüs verwendet, um 
das Menü zu identifizieren bzw. um dem Programm mitzuteilen, 
welches Menü ausgewählt wurde. Diese Menu-ID ist unabhängig 
von der Resource-ID der 'MENU'-Resource, normalerweise werden 
jedoch Menu-ID und 'MENU’-Resource-ID auf denselben Wert 
gesetzt, um Verwechslungen zu vermeiden. 


11.2 Routinen und 
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Zeile 3 spezifiziert die Art des Menüs. Es wird durch die soge- 
nannte "textMenuProc" definiert (ein ganz normales Menü). Der MDEFs (Menu- 
Menu-Manager bietet auch die Möglichkeit (wie der Window- _Definition-Functions) 
Manager), eigene Menu-Definition-Functions (MDEF) zu ver- sind für die Darstellung 
wenden, d.h. selbst für die Darstellung und Verwaltung eines und Verwaltung von 
Menüs verantwortlich zu sein. Einige Programme verwenden Menüs zuständig. 
diese Möglichkeit des Menu-Managers, um beispielsweise Gra- 

fikmenüs einzusetzen. Solche MDEFs werden als eigenständige 

Code-Resources in einer Resource vom Typ 'MDEF abgelegt. In 

Zeile 3 der 'MENU'-Resource könnte dann die Resource-ID der 

selbstdefinierten 'MENU'-Resource angegeben werden, sie wäre 

dann für die Verwaltung und das Zeichnen dieses Menüs zu- 

ständig. 

In Zeile 4 wird die vordefinierte Konstante allEnabled verwen- 

det, um dem Menu-Manager mitzuteilen, daß sämtliche Menü- 

punkte dieses Menüs initial aktiviert (enabled = auswählbar) sind. 

Dieses Feld ist ein Bit-Feld, in dem jedes Bit mit einem Menü- 

punkt assoziiert wird. Ist das Bit 1, so ist der Menüpunkt initial 

aktiviert, ist es 0, so ist der Menüpunkt deaktiviert (disabled = 

kann nicht ausgewählt werden). Dieses Bit-Feld stellt die Vor- 

einstellung für das Aktivieren bzw. Deaktivieren der Menüpunkte 

dar, die einzelnen Menüpunkte können zur Laufzeit des Pro- 

gramms mit den entsprechenden Menu-Manager-Funktionen 

aktiviert bzw. deaktiviert werden. 

Zeile 5 spezifiziert mit der vordefinierten Konstanten enabled, daß 

das Menü selbst (der Menütitel) aktiviert werden soll. 

In Zeile 6 wird der Menütitel in Form eines Strings ("Ablage") 

vergeben. 

Die folgenden Zeilen definieren die einzelnen Menüpunkte. In 

Zeile 8 wird der Menüpunkt "Neu" definiert. Das dem Menü- 

punktnamen folgende Statement nolcon spezifiziert, daß dieser 

Menüpunkt kein Icon haben soll. An dieser Stelle kann die 

Resource-ID einer 'ICON'-Resource eingetragen werden, dieses 

Icon erscheint dann links neben dem Menüpunkt. 

Mit dem Buchstaben "N" wird der Menükurzbefehl spezifiziert, 

der mit diesem Menü assoziiert wird. 

Durch das Statement noMark wird dem Menu-Manager mitge- 

teilt, daß das Menü kein Häkchen bekommen soll. 
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Ein Menüpunkt mit dem 
Namen '-" definiert einen 
Trennstrich. 


Eine 'MBAR'-Resource 
faßt mehrere 'MENU"- 
Resources zu einer 
Menüleiste zusammen. 


Um ein Menü zu 
verwalten, verwendet 
der Menu-Manager eine 
Struktur vom Typ 
Menulnfo. 


Das letzte Statement dieser Menüpunktdefinition (plain) be- 
deutet, daß der Text des Menüpunktes ("Neu") mit normalem 
Schriftschnitt gezeichnet wird. Alternativen wären beispielsweise 
italic (kursiv) oder bold (fett). 

In Zeile 9 wird die Möglichkeit des Menu-Managers benutzt, 
Menüpunktgruppen mit einem Trennstrich visuell voneinander 


‘zu trennen. Ein Trennstrich ist dann definiert, wenn der Menü- 


punkt den Namen "-" trägt. Sie werden verwendet, um Menü- 
befehle in funktionale Gruppen zusammenzufassen, bzw. die 
Gruppen voneinander zu trennen. 


Ein weiterer Resource-Type des Menu-Managers ist die sogenannte 
'MBAR'-Resource. Solche 'MBAR'-Resources werden verwendet, 
um die Installation mehrerer Menüs auf wenige Befehle zu redu- 
zieren. Ein 'MBAR'-Resource enthält eine Liste von MENU'- 
Resource-IDs, sie stellt dadurch eine Zusammenfassung mehrerer 
Menü-Resources zu einer Menubar-Beschreibungs-Resource dar. 


1: resource 'MBAR' (128) { 

2 { 

3 128, /*"Apple" */ 
4: 129, /*"Ablage" %/ 
5 130 /*"Bearbeiten" */ 
6: } 

1:2}; 


Die 'MBAR'-Resource listet in Zeile 3 bis 5 die Resource-IDs (128- 
130) der 'MENU'-Resources auf, welche zu dieser Menüleiste 
gehören. 


Ist ein Menü in der Menüleiste installiert, so verwaltet der Menu- 
Manager die Informationen über das Menü mit einem Menu- 
Handle. Ein MenuHandle ist ein Handle auf ein struct vom Typ 
Menulnfo, welches wie folgt deklariert ist: 


1: struct Menulnfo { 

2: short menulD; 

3: short menuWidth; 
4: short menuHeight; 
5 Handle menuProc; 

6 long enableFlags; 
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TE Str255 menuData; 
8: }; 
98 
10: typedef struct Menulnfo Menulnfo; 
11: typedef Menulnfo *MenuPtr, **MenuHandle; 


Die Struktur enthält zunächst das Feld menulD. Viele Menu- 
Manager-Routinen erwarten als Eingabeparameter eine Menu- 
ID, um zu spezifizieren, mit welchem Menu gearbeitet werden 
soll. Diese Menu-ID wird vom Menu-Manager auch bei der 
Menüauswahl verwendet; wenn der Benutzer einen Menüpunkt 
ausgewählt hat, so gibt der Menu-Manager diese Menu-ID in 
Verbindung mit der Menüpunktnummer an das Programm zu- 
rück. 

Die Felder menuWidth bzw. menuHeight geben die Breite bzw. 
Höhe des ausgeklappten Menüs in Punkten an. 

Der Handle menuProc verweist auf die geladene Menu-Defini- 
tion-Function (MDEF). 

Das Feld enableFlags enthält ein Bit-Feld, welches spezifiziert, 
welche der Menüpunkte aktiviert bzw. deaktiviert sind. Jedes 
Bit dieses Feldes ist dabei mit einem Menüpunkt assoziiert. 
Das Feld menuData enthält den Menütitel des Menüs. Hinter 
diesem Feld folgen die Menüpunkte. Da diese Felder von variabler 
Länge sind und (je nach MDEP) unterschiedlichen Inhalts sein 
können, sind sie nicht in dieser Datenstruktur deklariert. 


Bevor die Routinen und Datenstrukturen des Menu-Managers _InitMenus 
verwendet werden können, muß dieser Manager initialisiert 
werden. Dies geschieht mit der Funktion InitMenus. 


pascal void InitMenus (void); 


Um eine 'MENU'-Resource zu laden, stellt der Menu-Manager GetMenu 
die Funktion GetMenu zur Verfügung. 


pascal MenuHandle GetMenu (short resourcelD); 


Diese Funktion lädt die Menübeschreibungs-Resource, welche 
die Resource-ID hat, die in dem Parameter resourcelD enthalten 


219 


Kapitel 11 


Menüs 





220 


InsertMenu 


DeleteMenu 


ist, und gibt den Handle auf die geladene Resource als Ergebnis- 
wert an das Programm zurück. 


Der von GetMenu zurückgegebene MenuHandle kann an die 
Funktion InsertMenu übergeben werden, um das Menü in der 
Menüleiste zu installieren. 


pascal void InsertMenu ( 
MenuHandle theMenu, 
short beforelD); 


InsertMenu installiert das Menü, welches mit dem MenuHandle 
theMenu verwaltet wird, in der Menüleiste. Das neue Menü wird 
vor dem Menü installiert, welches mit dem Parameter beforeID 
spezifiziert wird. Wenn das neue Menü hinter allen anderen 
angehängt werden soll, so übergibt man anstelle von beforeID den 
Wert. 

Nachdem das neue Menü mit der Funktion InsertMenu in die 
Menüleiste eingebunden wurde, muß noch durch einen Aufruf 
der Funktion DrawMenußBar dafür gesorgt werden, daß die 
Menüleiste neu gezeichnet wird. 


Soll ein Menü wieder aus der Menüleiste entfernt werden, so 
steht die Funktion DeleteMenu zur Verfügung. Bei der Verwen- 
dung von DeleteMenu ist darauf zu achten, daß es auf dem Mac- 
intosh vermieden werden sollte, die Menüleiste häufig zu ver- 
ändern, da dies zu einer Verwirrung des Benutzers führt. Das 
Löschen bzw. Einfügen eines Menüs oder Menüpunktes zur 
Laufzeit des Programms bewirkt eine modale Strukturierung des 
Programms und führt dadurch zu dessen Unübersichtlichkeit. 
Eine Alternative zum Entfernen eines Menüs besteht darin, dieses 
Menü (bzw. die Menüpunkte) je nach Programmzustand zu ak- 
tivieren bzw. zu deaktivieren. Der Vorteil dieser Konzeption be- 
steht darin, daß der Benutzer weiterhin den gesamten Funktion- 
sumfang des Programms überblicken kann. 


pascal void DeleteMenu (short menulD); 


Die Funktion DeleteMenu löscht das Menü, das die als Parame- 
ter übergebene Menu-ID besitzt, aus der Menüleiste. 
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Viele Menu-Manager-Funktionen erwarten einen Handle auf das 
installierte Menü, um zu spezifizieren, mit welchem Menü gear- GetMHandle 
beitet werden soll. Diesen MenuHandle auf ein installiertes Menü 

kann man sich mit der Funktion GetMHandle heraussuchen lassen, 

um den Ergebniswert dieser Funktion als Parameter für andere 
Menu-Manager-Funktionen zu verwenden. 


pascal MenuHandle GetMHandle (short menulD); 


GetMHandle gibt den Handle auf das installierte Menü mit der 
Menu-ID zurück, welches durch den Parameter menulD spezi- 
fiziert wird. 


Soll innerhalb eines Menüs ein neuer Menüpunkt eingefügt InsMenultem 
werden, so kann die Funktion InsMenultem verwendet werden. 
Auch bei der Verwendung dieser Funktion ist Vorsicht in bezug 
auf das User-Interface des Programms angebracht. Das Einfügen 
bzw. Löschen eines Menüpunktes ist ein (eigentlich zu vermei- 
dender) Modus. Diese Funktion wird häufig dazu verwendet, 
um die Namen von geöffneten Fenstern in einem "Fenster"-Menü 
einzutragen. Wenn der Benutzer einen Menüpunkt aus diesem 
Menü auswählt, so wird das entsprechende Fenster nach vorne 


geholt. 

pascal void InsMenultem ( 
MenuHandle theMenu, 
Str255 *itemString, 
short afterltem); 


InsMenultem fügt einen neuen Menüpunkt in das Menü ein, auf 
das der MenuHandle theMenu zeigt. Der neue Menüpunkt erhält 
den Namen, der mit dem String itemString spezifiziert wird und 
wird in der Reihenfolge der Menüpunkte hinter dem Menüpunkt 
mit der Nummer afterltem eingetragen. Die Reihenfolge der 
Menüpunkte ist durch einfache Durchnumerierung festgelegt. 


Soll ein Menüpunkt entfernt werden, so kann die Funktion DelMenultem 
DelMenultem verwendet werden. Bei der Verwendung dieser 
Funktion ist (wie bei InsMenultem) darauf zu achten, daß nicht 


ständig neue Menüpunkte eingefügt bzw. entfernt werden. 901 
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AddResMenu 


Schriften sind als 
'FOND'-Resources im 
System installiert. 


Unter System 6 sind 
Schreibtischprogramme 
(DAs) als 'DRVR'- 
Resources im System 
installiert. 


pascal void DelMenultem ( 
MenuHandle theMenu, 
short item); 


DelMenultem entfernt den Menüpunkt mit der Nummer item aus 
dem Menü, welches mit theMenu spezifiziert wird. 


Die Funktion AddResMenu wird dazu verwendet, um Menüs, 
deren Inhalt erst zur Laufzeit bestimmt werden kann, mit Menü- 
punkten auf der Basis von Resource-Namen zu füllen. Diese 
Funktion wird beispielsweise von Textverarbeitungsprogramm- 
en dazu verwendet, das "Schrift"-Menü mit den Schriftnamen zu 
füllen. Da der Benutzer die Schriften im System installieren und 
entfernen kann, ist der Inhalt eines "Schrift"-Menüs erst zur Laufzeit 
des Programms bekannt, kann also nicht vordefiniert werden. 
Textverarbeitungsprogramme verwenden die Funktion Add- 
ResMenu dazu, um unter dem "Schrift"-Menü die Schriftnamen 
einzutragen, indem sie dieser Funktion den Auftrag geben, die 
Resource-Namen sämtlicher 'FOND'-Resources einzutragen. Diese 
FOND-Resources des Systems entsprechen den Schriften, die als 
Resources im System eingebunden sind. Da alle'FOND'-Resources 
den korrespondierenden Schriftnamen als Resource-Namen be- 
sitzen, trägt AddResMenü alle Schriftnamen in dem "Schrift"- 
Menü ein. 

Diese Funktion wird auch zur Erstellung des (ebenfalls dynami- 
schen) "Apple"-Menüs verwendet. Anstelle der'FOND'-Resources 
werden dann die 'DRVR'-Resource-Namen im "Apple"-Menü 
eingetragen. Hinter den 'DRVR'-Resources verbergen sich die 
Schreibtischprogramme (DAs), die (wie die Schriften) im System 
installiert sind. 


pascal void AddResMenu ( 
MenuHandle theMenu, 
ResType theType); 


Die Funktion AddResMenu hängt die Resource-Namen aller 
Resources, die einem bestimmten Resource-Type entsprechen, 
als Menüpunkte an ein Menü an. Das Menü, an welches die 
Menüpunkte angehängt werden sollen, wird durch den Para- 
meter theMenu angegeben. Der Resource-Type, unter dem ge- 
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sucht werden soll, wird durch den Parameter theType spezifi- 
ziert. 


Wenn der Benutzer den Menüpunkt eines dynamischen Menüs _Getitem 
(wie z.B. Schrift- oder "Apple"-Menü) auswählt, so wird die 
Funktion Getltem verwendet, um Informationen über den Namen 

des ausgewählten Menüpunktes zu erhalten. Bei einem "Schrift"- 

Menü wird der Name der ausgewählten Schrift dann mit Hilfe 

des Font-Managers in die ausgewählte Schrift umgesetzt, bei der 
Auswahl eines Schreibtischprogramms wird das ausgewählte 
Schreibtischprogramm anhand seines Namens gestartet. 


pascal void GetItem (MenuHandle theMenu, 
short item, 
Str255 *jtemString); 


Die Funktion Getltem gibt den Namen des Menüpunktes in dem 
String, dessen Adresse bei itemString übergeben wird, zurück. 
Der Menüpunkt wird dabei durch die Menüpunktnummer item 
bzw. durch den MenuHandle theMenu spezifiziert. 


Ein alternativer (und leichterer) Weg, um mehrere neue Menüs GetNewMBar 
mit Hilfe einer 'MBAR'-Resource zu installieren, liegt in der 
Verwendung von GetNewMBar. Diese Funktion erlaubt es, in 
Kombination mit SetMenuBar mehrere Menüs gleichzeitig zu in- 

stallieren. 


pascal Handle GetNewMBar (short menuBarID); 


Die Funktion GetNewMBar lädt die 'MBAR'-Resource mit der 
ID, die bei menuBarlID übergeben wird, mit Hilfe des Resource- 
Managers in den Speicherbereich der Applikation. Der Handle 
auf diese geladene 'MBAR'-Resource wird als Ergebniswert an 
das Programm zurückgegeben. . 


Der Ergebniswert von GetNewMBar kann an SetMenuBar über- SetMenuBar 

geben werden. SetMenuBar lädt dann automatisch alle 'MENU'- 

Resources, deren IDs in der 'MBAR'-Resource enthalten sind und 

installiert diese in der Menüleiste. Die Kombination von Get- 

NewMBar und SetMenuBar ersetzt ein wiederholtes GetMenu 223 
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DrawMenuBar 


Menuselect 


bzw. InsertMenu und stellt damit eine Vereinfachung der Instal- 
lation dar. 


pascal void SetMenuBar (Handle menulist); 


SetMenuBar installiert alle Menüs, die in der übergebenen 
Menüliste (MBAR'-Resource) enthalten sind, in die Menüleiste 


‚der Applikation. 


Um Veränderungen der Menüleiste (neue Menüs oder Menüs 
gelöscht) sichtbar zu machen, wird die Funktion DrawMenuBar 
aufgerufen. Sie zeichnet die gesamte Menüleiste neu, so daß die 
Veränderungen sichtbar werden. 


pascal void DrawMenuBar (void); 


Wenn der Benutzer in die Menüleiste klickt (FindWindow hat 
den Wert inMenuBar zurückgegeben), so sollte die Funktion 
MenusSelect aufgerufen werden, um dem Benutzer die Menü- 
auswahl zu ermöglichen. MenuSelect übernimmt die Kontrolle, 
klappt das getroffene Menü herunter und läßt den Benutzer einen 
Menüpunkt aus den Menüs auswählen. Diese Funktion behält 
solange die Kontrolle, bis der Benutzer die Maustaste losgelassen 
hat. Wenn MenusSelect die Kontrolle zurückgibt (der Benutzer 
hat einen Menüpunkt ausgewählt), verzweigt das Programm 
üblicherweise in Aktionsroutinen, die dann auf den ausgewählten 
Menüpunkt reagieren. 


pascal long MenuSelect (Point startPt); 


Menuselect erwartet als Eingabeparameter die Startkoordinaten 
des Mausklicks. Diese Koordinaten entsprechen dem where-Feld 
des EventRecords bei einem MouseDown-Event. 

Hat der Benutzer die Maustaste losgelassen, so gibt MenuSelect 
die Auswahl in dem Ergebniswert der Funktion an das Programm 
zurück. Die Auswahl des Benutzers (welcher Menüpunkt aus 
welchem Menü) ist in dem zurückgegebenen long enthalten. Das 
Hi-Word des longs enthält die Menu-ID, das Lo-Word enthält 
die Menüpunktnummer des ausgewählten Menüpunktes. 


Wenn der Benutzer die Maustaste außerhalb der Menüs losgelassen 
oder einen deaktivierten Menüpunkt ausgewählt hat, so enthält 
das Hi-Word des Ergebniswertes den Wert 0. 
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Wenn in der Main-Event-Loop ein KeyDown-Event eintrifft, der 
im modifiers-Feld des Event-Records das Command-Key-Flag 
gesetzt hat, so hat der Benutzer einen Menükurzbefehl getippt 
(z.B. Befehlstaste-Q für "Beenden”). Um herauszufinden, welcher 
Menüpunkt aus welchem Menü ausgewählt wurde, wird die 
Funktion MenuKey aufgerufen. Diese Funktion sucht in der Li- 
ste der Menüs nach einem Menüpunkt mit dem entsprechenden 
Kurzbefehl. 


pascal long Menukey (short ch); 


Bei einem Aufruf von MenuKey muß der ASCII-Code der ge- 
drückten Taste als Parameter übergeben werden. Die Codierung 
des Ergebniswertes der Funktion entspricht der von MenusSelect: 
Das HiWord des zurückgegebenen longs enthält die Menu-ID, 
das Lo-Word die Menüpunktnummer des ausgewählten Menü- 
punktes. 


Die Funktion HiliteMenu kann dazu verwendet werden, um den 
Menütitel eines bestimmten Menüs hervorzuheben (zu invertieren). 
Die Funktionen MenuSelect bzw. MenuKey erledigen dieses 
Auswählen des Menütitels automatisch, Macintosh-Programme 
verwenden diese Funktion eigentlich nur, um diese Hervorhe- 
bung wieder aufzuheben. 

Wenn der Benutzer einen Menüpunkt ausgewählt hat, so bleibt 
der entsprechende Menütitel invertiert. Die Applikation reagiert 
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Abb. 11-5 

Die Abbildung illustriert 
den Ergebniswert der 
Funktion MenuSelect. 
Die Menu-ID des 
ausgewählten Menüs ist 
im Hi-Word, die 
Menüpunktnummer des 
ausgewählten Menü- 
punktes im Lo-Word 
des zurückgegebenen 
longs enthalten. 


MenukKey 


HiliteMenu 
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Disableltem 


Enableltem 


Checkltem 


mit der korrespondierenden Aktion und hebt die Auswahl des 
Menütitels anschließend wieder auf. Wenn die Aktion länger 
dauert, so ist der hervorgehobene Menütitel ein Hinweis für den 
Benutzer, daß der Menübefehl noch abgearbeitet wird. 


pascal void HiliteMenu (short menulD); 


Die Funktion HiliteMenu hebt den Menütitel des Menüs hervor, 
dessen Menu-ID übergeben wird. Wird dieser Funktion der Wert 
0 übergeben, so hebt sie die letzte Menüauswahl wieder auf. 


Soll ein Menüpunkt zur Laufzeit "abgeschaltet" (disabled) wer- 
den, so wird die Funktion Disableltem aufgerufen. Menüpunkte, 
die disabled sind, werden grau gezeichnet und können nicht 
ausgewählt werden. Die Verwendung dieser Technik ist (wenn 
immer möglich) dem Entfernen eines Menüpunktes vorzuzie- 
hen, da dem Benutzer die Übersicht über die Funktionalitäten 
des Programms erhalten bleibt. 


pascal void DisableItem ( MenuHandle theMenu, 
short item); 


Bei einem Aufruf der Funktion Disableltem wird der abzu- 
schaltende Menüpunkt durch den MenuHandle theMenu bzw. 
durch die Menüpunktnummer item spezifiziert. Der Menüpunkt 
erscheint dann grau und ist nicht mehr auszuwählen. 


Um einen abgeschalteten Menüpunkt wieder anzuschalten, wird 
die Funktion Enableltem verwendet. Sie hebt die Auswirkungen 
von Disableltem wieder auf. 


pascal void EnableItem ( MenuHandle theMenu, 
short item); 


Der einzuschaltende Menüpunkt wird (wie bei Disableltem) durch 
den MenuHandle und die Menüpunktnummer spezifiziert. 


Viele Programme erlauben die Auswahl sogenannter "Check Menu 
Items". Wird das Menü ausgewählt, so wird ein kleines Häkchen 
vor dem Menüpunkt gezeichnet. Wird es noch einmal ausgewählt, 
so verschwindet dieses Häkchen wieder. Ein Beispiel für einen 


solchen Menüpunkt ist der "Kursiv"- oder "Fett"-Menüpunkt des 
"Stil"-Menüs eines Textverarbeitungsprogramms. Diese Art von 
Menüpunkten schaltet Teile des Programms in einen anderen 
Zustand um. Wird im vorangegangenen Beispiel nach Auswahl 
des "Kursiv"-Menüpunktes Text eingegeben, so erscheint dieser 
in kursiver Form. Das Häkchen an dem Menüpunkt ist eine 
Rückmeldung an den Benutzer, daß der aktuelle Text in kursiver 
Form gezeichnet wird. 


pascal void CheckItem ( MenuHandle theMenu, 
short item, 
Boolean checked); 


Der Menüpunkt, der ein Häkchen bekommen oder dem es wie- 
der weggenommen werden soll, wird durch den MenuHandle 
theMenu und die Menüpunktnummer item spezifiziert. Mit dem 
Boolean checked kann angegeben werden, ob der Menüpunkt 
ein Häkchen bekommen, oder ob es entfernt werden soll. 


11.3  MINIMUM3 - Das Programm bekommt Menüs 


Minimum installiert die typischen Standard-Menüs einer Mac- 


intosh-Applikation ("Apple"-, "Ablage"- und "Bearbeiten"-Menü) 
in der Menüleiste des Programms. 


% Ablage Bearbeiten 
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Abb. 11-6 

Die Grafik zeigt das 
laufende Programm mit 
installiertem "Apple'-, 
"Ablage"- und "Bearbei- 
ten’-Menü. 
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Abb. 11-7 
Die Grafik zeigt die 


Menüs des Programms 
Minimum3. Die Namen 


der Menüpunkte, ihre 
Reihenfolge sowie die 


Kurzbefehle entsprechen 
den gültigen Macintosh- 
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Standards. 


In der derzeitigen Version der Applikation wird nur das "Apple"- 
und das "Ablage"-Menü unterstützt. Wählt der Benutzer einen 
Menüpunkt aus dem "Apple"-Menü aus, so wird das entsprechende 
Schreibtischprogramm gestartet. Wird der "Beenden"-Menüpunkt 
aus dem "Ablage"-Menü ausgwählt, so terminiert die Applikation. 
Alle anderen Standard-Menüpunkte können zwar ausgewählt 
werden, es verbirgt sich jedoch noch keine Funktionalität hinter 
diesen Menüpunkten. 


Ablage 
Neu 
Dffnen... 









Bearbeiten 


Widerrufen %*2 









Über Minimum... 






Schließen Ausschneiden &#H 


Album 





S Ruswahl Kopieren &C 
2] Kontrolifelder Sichern Einsetzen »U 
Sichern unter... Loschen 
K] Notizblock 
Puzzle Seitenformat... Zwischenablage 
| Rechner Drucken... &#P 
[Z) Tastatur 
& Wecker Beenden *0 


Um die Unterstützung für die Menüverwaltung zu implemen- 
tieren, wurden die folgenden Änderungen bzw. Neuerungen am 
Quelltext der Applikation vorgenommen: 


1. Die ToolBox-Initialisierungsroutine Init_ToolBox wurde um 
die Initialisierung des Menu-Managers erweitert. 


2. Die neue Funktion Make _Menus übernimmt die Installation 
der Menüs. Die Menüleiste wird mit Hilfe einer 'MBAR'-Resource, 
die Verweise auf die zu installierenden Menüs enthält, instal- 
liert. 


3. Die Funktion Do_MouseDown wurde so erweitert, daß sie in 
der Lage ist, auf Mausklicks in die Menüleiste zu reagieren. Sie 
erlaubt dem Benutzer die Auswahl eines Menüpunktes und ver- 
zweigt dann in die Menübehandlungsroutine Do_MenuCommand. 


4. Do_MenuCommand ist eine neue Funktion, die anhand des 
Menüs, in dem sich der ausgewählte Menüpunkt befindet, in 
spezialisiertere Menübehandlungsroutinen verzweigt. Diese 
Menübehandlungsroutinen behandeln jeweils ein komplettes 





Menü. Do_MenuCommand bildet den Grundstamm für die 
Menübehandlung, sie ist die Schaltzentrale für die Menü- 
Aktionsroutinen, die auf die ausgewählten Menüs reagieren. 


5. Die Menübehandlungsroutine für das "Apple"-Menü heißt 
Do_AppleMenu. Diese Funktion entscheidet anhand des ausge- 
wählten Menüpunktes, welche Aktionen durchgeführt werden. 
Da das "Über Minimum..."-Menü bisher noch nicht unterstützt 
wird, kümmert sich diese Funktion ausschließlich um den Auf- 
ruf der Schreibtischprogramme. 


6. Do_FileMenu behandelt die Menüpunkte des "Ablage"-Menüs. 
Diese Funktion ruft die eigentlichen Aktionsroutinen auf. Die 
Aktionsroutinen reagieren dann auf den ausgewählten Menü- 
punkt. 


7. Eine solche Aktionsroutine ist die neue Funktion Do_Quit. Diese 
Funktion wird von Do_FileMenu aufgerufen, wenn der Benut- 
zer den "Beenden"-Menüpunkt ausgewählt hat. Do_Quit beendet 
die Applikation, indem sie das globale Terminationskriterium 
setzt. Das Programm verläßt die Main-Event-Loop und terminiert. 


8. Um Menü-Kurzbefehle zu unterstützen, behandelt Minimum3 
jetzt auch KeyDown-Events. Die modifizierte Do_Event-Routi- 
ne ruft jetzt die neue Event-Behandlungsroutine Do_KeyDown 
auf, wenn eine Taste in Kombination mit der Befehlstaste ge- 
drückt wurde. 


9. Do_KeyDown benutzt die Menu-Manager-Funktion MenukKey, 
um herauszufinden, welchem Menüpunkt der ausgewählte 
Kurzbefehl entspricht und ruft dann die Menübehandlungsroutine 
Do_MenuCommand auf. 
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| Init_ToolBox 


' 


[| Make_Menus 


' 


Make_Window 


u 


Main >| Do_Event N 


' 


Abb. 11-8 

Die Grafik zeigt den 
veränderten Kontrollfiuß 
in Minimum3. Die 
veränderten bzw. neuen 
Routinen sind hervorge- 
hoben. 
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„ Set_DrawingClip 
4_Do_Update 
=  Draw_Graphics 
Do_GrowWindow 
P2 Do_ZoomWindow 
»-| Do_MouseDown K—e Do_DragWindow 
N Do_CloseWindow 
», Do_AppleMenu 
\ Do_KeyDown S Do_MenuCommand } 


"| Do_FileMenu - Do_Quit 
\ 


Do_Activate 


Im Nachfolgenden werden die geänderten bzw. die neuen Rou- 
tinen von Minimum3 analysiert: 


Zunächst wird eine neue Interface-Datei benötigt, um mit den 
Routinen und Datenstrukturen des Menu-Managers arbeiten zu 
können. Diese Interface-Datei wird mit Hilfe des #include- 
Statements in Zeile 7 in den Quelltext eingebunden. 


: #include <Types.h> 

: #include <QuickDraw.h> 
: #include <Fonts.h> 

: #include <Windows.h> 

: #include <Events.h> 

: #include <ToolUtils.h> 
: #include <Menus.h> 


Sau »$wnßNnH 


Minimum3 besitzt eine Reihe von Konstanten, die zur "Lesbar- 
keit" des Quelltextes beitragen sollen. Diese Konstanten entspre- 
chen den benötigten Resource- bzw. Menu-IDs und den Menü- 
punktnummern. Um den Kontext der Konstanten in ihrem Na- 
men auszudrücken, beginnen Resource-IDs mit einem kleinen 
"r", Menu-IDs mit "m" und Menüpunktnummern (items) mit "i". 


HFHrHHrrHrrrr 
SUBWNDHOS DO NINAUIBWMN H 


r 
SI 


PH 
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: /* Resource - IDs */ 


: #define rMenuBar 128 // 
: /* Menu - IDs */ 

: #define mApple 128 // 
: #define mFile 129 // 
: #define mEdit 130 // 


: /* "Apple" - Menüpunkte */ 
: #define iAbout 1 // 


: /*% "Ablage" - Menüpunkte */ 


: #define iNew 1 // 
: #define iOpen 2 // 
: #define iClose 3 // 
: #define iSave 5 // 
: #define iSaveAs 6 // 
: #define iPageSetup 7 // 
: #define iPrint 9 // 
: #define iQuit 11 /I/ 


Die modifizierte Funktion Init_ToolBox: 


1% 
2 
33 
4: 
5: 
6 
7 


In Zeile 6 wird der Menu-Manager initialisiert, damit dessen 


void Init_ToolBox (void) 


{ 


MBAR-Resource-ID 


"Apple"-Menu 
"Ablage"-Menu 
"Bearb."-Menu 


"Über Minimun..." 


"Neu" 

"Öffnen..." 
"Schließen" 
"Sichern" 
"Sichern unter..." 
"Seitenformat..." 
"Drucken..." 
"Beenden" 


InitGraf ((Ptr) &qd.thePort); 


InitFonts (); 
InitWindows (); 
InitMenus (); 


} 


Routinen und Datenstrukturen verwendet werden können. 


Die neue Funktion Make_Menus: 


: void Make Menus (void) 


a 


Handle menuBar; 
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Resource-ID-Konstan- 
ten beginnen mit 'r" 


Die Menu-ID-Konstan- 
ten beginnen mit 'm". 


Die Konstanten für die 
Menüpunktnummern 
beginnen mit 'i" (items). 


Init_ToolBox ruft jetzt 
InitMenus auf, um den 
Menu-Manager zu 
initialisieren. 


Make_Menus installiert 
die Menüleiste. 
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Die 'MENU'-Resources 
sind in einer 'MBAR'- 
Resource mit der ID 128 
zusammengefaßt. 


5% menuBar = GetNewMBar (rMenuBar); 

6: SetMenuBar (menuBar); 

I DisposHandle (menuBar); 

8: AddResMenu (GetMHandle (mApple), 'DRVR'); 
9: DrawMenuBar (); 

10: } 


Die Funktion Make_Menus lädt in Zeile 5 die MBAR'-Resource, 
die Verweise auf die zu installierenden Menüs ("Apple", "Abla- 
ge", "Bearbeiten") enthält, mit Hilfe der Funktion GetNewMBar. 
Der Handle auf die geladene 'MBAR'-Resource wird in Zeile 6 
an die Funktion SetMenuBar übergeben, die die Menüleiste in- 
stalliert. SetMenuBar lädt die in der 'MBAR'-Resource spezifi- 
zierten 'MENU'-Resources und installiert sie durch Aufrufe von 
InsertMenu. Da die geladene 'MBAR'-Resource nicht mehr be- 
nötigt wird, wird sie in Zeile 7 durch den Aufruf von Dispose- 
Handle zum Überschreiben freigegeben. 

In Zeile 8 werden die Namen der Schreibtischprogramme mit 
Hilfe der Funktion AddResMenu im "Apple"-Menü installiert. 
Der Funktion wird der Ergebniswert von GetMHandle überge- 
ben, welche den Handle auf das bereits installierte "Apple"-Menü 
zurückliefert. Damit AddResMenu die Namen aller Schreib- 
tischprogramme im "Apple"-Menü einträgt, wird dieser Funk- 
tion der Resource-Type 'DRVR' übergeben (alle Schreibtisch- 
programme sind durch den Resource-Type 'DRVR' gekenn- 
zeichnet). 

Zeile 9 sorgt schließlich mit einem Aufruf von DrawMenußBar 
dafür, daß die neue Menüleiste gezeichnet wird. 


Neue Resources: 


Die Applikation hat eine MBAR'-Resource (die auf die zu instal- 
lierenden 'MENU'-Resources verweist) und drei 'MENU'-Resources 
("Apple", "Ablage" und "Bearbeiten"). Die 'MENU'-Resources 
wurden mit Hilfe von ResEdit erstellt und dann in der MPW- 
Shell durch das DeRez-Tool in Resource-Description-Statements 
übersetzt: 


Die 'MBAR'-Resource: 


1: resource 'MBAR' (128) { 

2 { 

3 128, /*"Apple" *“/ 
4: 129, /*"Ablage" */ 
5 130 /*"Bearbeiten" */ 
6: } 

IT: 


Die 'MBAR'-Resource enthält die Resource-IDs der zu installie- 
renden 'MENU'-Resources (128, 129, 130). 


Das "Apple"-Menü: 


resource 'MENU' (128) { 


1: 

2 128, 

34 textMenuProc, 

4: allEnabled, 

5% enabled, 

6 apple, 

g { 

8 "Über Minimum..", noIcon, nokey, noMark, 
plain, 

9: "-", nolcon, noKey, noMark, plain 

10: } 

11%}; 


Die 'MENU'-Resource für das "Apple"-Menü (ID = 128) beginnt 
in Zeile 2 mit der Definition der Menu-ID. Hier wird (um Ver- 
wirrungen zu vermeiden) die Menu-ID der Menu-Resource-ID 
gleichgesetzt. 

Zeile 3 spezifiziert, daß das Menü ein normales Text-Menü sein 
soll, indem die Konstante textMenuProc verwendet wird. 

Mit der vordefinierten Konstante allEnabled wird in Zeile 4 
spezifiziert, daß sämtliche Menüpunkte des Menüs aktiviert 
werden sollen. 

Zeile 5 sorgt dafür, daß das Menü selbst (der Menütitel) aktiviert 
wird, indem die Konstante enabled verwendet wird. 

Der Name des Menüs (das Apfel-Symbol) wird über den Spezial- 
Buchstaben definiert, der durch die vordefinierte Konstante "apple" 
an dieser Stelle eingesetzt wird. 
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Die |'MBAR'-Resource 
enthält die Verweise auf 
die MENU'-Resources, 
welche zu der Menü- 
leiste gehören. 


Das 'Apple'-Menü ist ein 
dynamisches Menü. 
Vordefiniert sind nur die 
Menüpunkte "Über 
Minimum..." bzw. der 
Trennstrich. Die Namen 
der Schreibtischpro- 
gramme werden erst zur 
Laufzeit eingetragen. 
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Das "Ablage'-Menü 
enthält die üblichen 
Menüpunkte. In der 
derzeitigen Version von 
Minimum wird jedoch 
nur der "Beenden'- 
Menüpunkt unterstützt. 





Zwischen den geschweiften Klammern (Zeile 7 bis 9) folgt die 
Definition der einzelnen Menüpunkte. Da der Inhalt des"Apple"- 
Menüs dynamisch ist (die Menüpunkte werden zur Laufzeit mit 
dem Aufruf von AddResMenu gesetzt), enthält dieses Menü nur 
den Menüpunkt "Über Minimum...". Das Statement nolcon, 
welches dem Menünamen folgt, teilt dem Menu-Manager mit, 
daß der Menüpunkt kein Icon haben soll. Da der "Über Mini- 
mum"-Menüpunkt kein Befehlstastenäquivalent haben soll, wird 
die Konstante noKey anstelle eines Buchstabens, der den Kurz- 
befehl spezifiziert, verwendet. Das Menü soll auch kein Häkchen 
bekommen, daher wird noMark verwendet. Das letzte Resource- 
Statement spezifiziert, daß der Textschnitt normal (plain) sein soll. 
Zeile 9 definiert einen Trennstrich nach dem ersten Menüpunkt, 
indem der Menüpunktname "-" verwendet wird. 


Das "Ablage"-Menü: 


1: resource 'MENU' (129) { 

2: 129, 

3: textMenuProc, 

4: allEnabled, 

5: enabled, 

6 "Ablage", 

7 { 

8 "Neu", nolcon, "N", noMark, plain, 

9: "Öffnen..", noIcon, "0", noMark, plain, 
10: "-", nolcon, noKey, noMark, plain, 
A "Schließen", nolcon, "W", noMark,plain, 
12: "Sichern", nolcon, "S", noMark, plain, 
13% "Sichern unter..", nolcon, nokey, 

noMark, plain, 
14: "-", nolcon, noKey, noMark, plain, 
15: "Seitenformat..", nolcon, noKey, noMark, 
plain, 

16: "Drucken..", nolcon, "P", noMark, plain, 
17: "-", nolcon, noKey, noMark, plain 
18: "Beenden", nolcon, "0", noMark, plain 
79: } 3 
20: }; 


Die Definition des "Ablage"-Menüs geschieht analog zur Defini- 
tion des "Apple"-Menüs. Der Menütitel wird in Zeile 6 durch 
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den String "Ablage" spezifiziert. Bei der Definition der Menü- 
punkte werden jetzt auch Menükurzbefehlsäquivalente definiert. 
Beispielsweise wird für den Menüpunkt "Neu" in Zeile 8 der 
Menükurzbefehl Befehlstaste-"N" reserviert, indem der Buch- 
stabe "N" angegeben wird. Dieser Buchstabe erscheint rechts ne- 
ben dem Menüpunkt und kann als alternative Menüauswahl 
verwendet werden. 


Das "Bearbeiten" - Menü: 


1: resource 'MENU' (130) { Das "Bearbeiten‘-Menü 
2 130, enthält die standardi- 
3: textMenuProc, sierten Menüpunkte. 
2 a SENSDIES, Obwohl dieses Menü 
58 enabled, es 
6 "Bearbeiten", von Minimum3 noch 
7 { nicht unterstützt wird, 
8: "widerrufen", nolcon, "Z",noMark,plain, istes dennoch in der 
9: "-", nolcon, noKey, noMark, plain, Menüleiste enthalten, 
10: "Ausschneiden",nolcon, "X",noMark,plain, um Schreibtischpro- 
11: ABDSSLeh! ‚ nolcon, "C", noMark, plain; gramme von der 
12: "Einsetzen", nolcon, "V", noMark,plain, j R 
13: "Löschen", nolcon, noKey, noMark,plain, Auswahl eines Menü- 
14: "-", nolcon, noKey, noMark, plain, punktes aus diesem 
15: "Zwischenablage", nolcon, noKey, Menü zu informieren. 
noMark, plain 
16: } 
17543 
Die Definition des "Bearbeiten"-Menüs erfolgt wie die Definition 
des "Ablage"-Menüs. 
Die modifizierte Version der Funktion Do_MouseDown: 
1: void Do_MouseDown (void) Do_MouseDown 
2: erkennt jetzt einen Klick 
gen uOrE Pate in die Menüleiste. 
4: WwindowPtr theWindow; 
5 
6 part = FindWindow (gEvent.where, 


&theWindow) ; 
switch (part) 
8: { 


I 
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9: case inDrag: 
10: Do_DragWindow (theWindow); 
1.1# break; 
12: 
13: case inZoomIn: 
14: case inZoomOut: 
15% Do _ZoomWindow (theWindow, part); 
16: break; 
17: 
18: case inGrow: 
19: Do_GrowWindow (theWindow); 
20: break; 
21: 
22: case inGoAway: 
Wenn der Benutzer in 23: Do CloseWindow (theWindow) ; 
die Menüleiste klickt, 24: break; 
wird die Funktion 2>: 
MenuSelect aufgerufen, 2°: case inMenuBar: 
welche es dem Benutzer = ee 
MenuSelect (gEvent.where)); 
ermöglicht, einen 28: brssr; 
Menüpunkt auszuwäh- 29: } 
len. 30: } 


Die Zeilen 26 bis 28 der erweiterten Version von Do_MouseDown 
sind die Reaktion des Programms auf einen Mausklick in die 
Menüleiste. Hat der Benutzer in die Menüleiste geklickt, so gibt 
FindWindow den Wert inMenuBar zurück. In diesem Fall rea- 
giert Do_MenuCommand, indem es die Menu-Manager-Funk- 
tion MenusSelect aufruft. MenuSelect übernimmt die Kontrolle 
und läßt den Benutzer einen Menüpunkt auswählen. Die Aus- 
wahl des Benutzers wird durch den Ergebniswert dieser Funk- 
tion (long) zurückgegeben. Dieser Ergebniswert wird anschließend 
an die Menübehandlungsroutine Do_MenuCommand weiter- 
gegeben, die auf das ausgewählte Menü reagiert. 


Die neue Funktion Do_MenuCommand: 


void Do MenuCommand (long choice) 


1; 
2 f 

3% short menulD, menultem; 
4 . 

5 


menulD = HiWord (choice); 
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6: menultem = LoWord (choice); 
7: 

8: switch (menulD) 

9% { 

10: case mApple: 

its Do _AppleMenu (menultem); 
12: break; 

13% 

14: case mFile: 

15: Do FileMenu (menultenm); 
16: break; 

17: 

18: case mEdit: 

19: SystemEdit (menultem -1 ); 
20: break; 
21: } 
22: HiliteMenu (0); 
23: } 


Do_MenuCommand extrahiert die Menu-ID bzw. die Menü- 
punktnummer aus dem Parameter, der dieser Funktion überge- 
ben wird (Ergebniswert von MenuSelect). Dies geschieht in Zei- 
le5 bzw. 6 mit den Aufrufen von HiWord bzw. LoWord. Das Hi- 
Word des Ergebniswertes von MenuSelect enthält die Menu-ID, 
das Lo-Word die Menüpunktnummer. 

Anhand des Menüs, in dem sich der ausgewählte Menüpunkt 
befindet (menulD), wird entschieden, welche der beiden spe- 
zialisierteren Menübehandlungsroutinen (Do_AppleMenu bzw. 
Do_FileMenu) aufgerufen wird. Diesen spezialisierten Menü- 
behandlungsroutinen wird die Menüpunktnummer des ausge- 
wählten Menüpunktes übergeben, damit sie entscheiden kön- 
nen, welche Aktionen durchgeführt werden müssen. 

In der derzeitigen Version unterstützt Minimum das "Bearbei- 
ten"-Menü noch nicht, Do_MenuCommand muß aus Kompati- 
bilitätsgründen dennoch auf die Auswahl eines Menüpunktes 
aus dem "Bearbeiten"-Menü reagieren. Wenn das Programm un- 
ter System 6 in der Single-Tasking-Umgebung "Finder" läuft, so 
muß das Programm dafür sorgen, daß DAs auf die Auswahl ei- 
nes "Bearbeiten"-Menüpunktes reagieren können. Hat der Benutzer 
einen Menüpunkt aus dem "Bearbeiten"-Menü ausgewählt, so 
wird in Zeile 20 die Desk-Manager-Funktion SystemEdit auf- 
gerufen. Diese Funktion sorgt dafür, daß Schreibtischprogramme 
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Do_MenuCommand 
entscheidet anhand der 
Menu-ID des Menüs, zu 
dem der ausgewählte 
Menüpunkt gehört, 
welche Routine 
aufgerufen wird. 


Das Hi-Word des 
Ergebniswertes von 
Menuselect enthält die 
Menu-ID, das Lo-Word 
die Menüpunktnummer. 


Wenn das Programm 
unter System 6 im 
normalen Finder 
(Single-Tasking) läuft, 
dann verhalten sich die 
Schreibtischprogramme 
wie Unterroutinen des 
Programms. Das 
Programm muß dann 
selbst dafür sorgen, daß 
die DAs von der 
Auswahl eines Menü- 
punktes informiert 
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Do_FileMenu reagiert 
auf die Auswahl des 
Menüpunktes 'Been- 
den“, indem die Funktion 
Do_Quit aufgerufen 
wird. 


Do_Quit setzt das 
globale Terminations- 
kriterium gQuit. 


auf eine Menüauswahl aus dem "Bearbeiten"-Menü reagieren 
können. Bei dem Aufruf dieser Funktion wird die Menüpunkt- 
nummer minus 1 übergeben, um SystemEdit mitzuteilen, welcher 
Menüpunkt ausgewählt wurde. Der Wert 0 bedeutet "Widerru- 
fen", 2 "Ausschneiden" usw. 

In Zeile 22 wird (nachdem die Menüaktionen durchgeführt wur- 
den) dafür gesorgt, daß der Menütitel des ausgewählten Menüs 
wieder normal gezeichnet wird (der Menütitel war invertiert). 
Dies geschieht, indem die Funktion HiliteMenu aufgerufen wird. 
HiliteMenu wird anstelle einer Menu-ID der Wert 0 übergeben, 
was bedeutet, daß das ausgewählte Menü wieder normal ge- 
zeichnet werden soll. 


Die neue Funktion Do_FileMenu: 


: void Do FileMenu (short menultem) 
{ 
switch (menultem) 
{ 
case iQuit: 
Do Quit (0; 
break; 


vooutePw%nmH 


o 


Die Funktion Do_FileMenu reagiert auf die Auswahl eines 
Menüpunktes aus dem "Ablage"-Menü, indem die entsprechen- 
den Aktionsroutinen aufgerufen werden. Zur Zeit wird nur der 
"Beenden"-Menüpunkt unterstützt, die Strukturen für eine Un- 
terstützung der anderen Menüpunkte aus diesem Menü sind je- 
doch bereits vorhanden. 


Die neue Funktion Do_Quit: 


1: void Do Quit (void) 
2: { 

3 gQuit = true; 

4: } 


Die Funktion Do_Quit übernimmt in der verbesserten Version 
von Minimum das Beenden der Applikation, indem die globale 





Variable gQuit auf true gesetzt wird. Das Programm verläßt die 
Main-Event-Loop und terminiert. 


Die neue Funktion Do_AppleMenu: 


1: void Do AppleMenu (short menultem) 
PER | 

3% short daRefNum; 

4: Str255 daName; 

SR 

6: switch (menultem) 

7 { 

8 default: 

9 GetItem (GetMHandle (mApple), 

menultem, daName); 

10: daRefNum = OpenDeskAcc (daName); 
11: break; 

12: } 
13:2. 


Die Funktion Do_AppleMenu ist für die Reaktion auf eine 
Menüauswahl aus dem "Apple"-Menü verantwortlich. Da das 
"Über Minimum..."-Menü noch nicht unterstützt wird, kann diese 


Funktion zur Zeit nur auf die Auswahl eines Schreibtischpro- 


gramms reagieren. Dies geschieht, indem in Zeile 9 die Funktion 
GetMHandle aufgerufen wird, die den Handle auf das instal- 
lierte Menü, welches durch die übergebene Menu-ID spezifiziert 
wird, als Ergebniswert liefert. Aus diesem Menü wird dann mit 
Hilfe der Funktion Getltem der Menüpunktname des ausge- 
wählten Menüpunktes herausgesucht und in den übergebenen 
String geschrieben. Die lokale Variable daName (welche jetzt den 
Namen des Schreibtischprogramms enthält) wird dann in Zeile 
10 dazu verwendet, um mit Hilfe der Desk-Manager-Funktion 
OpenDeskAcc das Schreibtischprogramm zu starten. Open- 
DeskAcc lädt das Schreibtischprogramm und übergibt die Kon- 
trolle an dieses Hilfsprogramm. 

Der Desk-Manager wurde bisher nicht näher beschrieben, da die 
Programmierung von Schreibtischprogrammen nicht Teil dieses 
Buches ist, und das Starten eines Schreibtischprogrammes die 
einzige Berührungsstelle zwischen Programmen und dem Desk- 
Manager darstellt. 
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Do_AppleMenu reagiert 
auf die Auswahl eines 
Menüpunktes aus dem 
"Apple'-Menü, indem 
das ausgewählte 
Schreibtischprogramm 
gestartet wird. 


Der Desk-Manager 
enthält Routinen, die für 
die Verwaltung von 
Schreibtischprogramm- 
en zuständig sind. Die 
Verwendung dieser 
Routinen wird notwen- 
dig, um die Kompatibili- 
tät zur Single-Tasking- 
Umgebung des Finders 
unter System 6 zu 
gewährleisten. 
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Do_Event reagiert jetzt 
auf KeyDown-Events, 
indem die Funktion 
Do_KeyDown aufgeru- 
fen wird. 


Do_KeyDown überprüft, 
ob es sich bei dem 
KeyDown-Event um 
einen Menükurzbefehl 
handelt (Befehlstaste + 
normale Taste). 


Die modifizierte Version der Funktion Do_Event: 


1: void Do Event (void) 
2: { 
3 switch (gEvent.what) 
4 { 
Sr case mouseDown: 
6: Do_MouseDown (); 
ER break; 
8: 
9: case keyDown: 
10: case autoKey: 
11: Do _KeyDown (); 
12% break; 
13: 
14: case updateEvt: 
15: Do _ Update (); 
16: break; 
17: 
18: case activatebvt: 
19: Do Activate (); 
20: break; 
21: } 
22: } 


Um die Auswahl eines Menüpunktes mit Hilfe eines Menükurz- 
befehls zu ermöglichen, wurde die Funktion Do_Event in den 
Zeilen 9 bis 12 um die Behandlung von KeyDown- bzw. AutoKey- 
Events erweitert. 

Bei diesen Events verzweigt die Funktion in die Event-Behand- 
lungsroutine Do_KeyDown, die überprüft, ob es sich um einen 
Menükurzbefehl handelt, und daraufhin die Auswahl des 
Menüpunktes ermöglicht. 


Die neue Funktion Do_KeyDown: 


: void Do _KeyDown (void) 
{ 


char key; 


if (gEvent.modifiers & cmdKey) 
{ 


au b$wWN Hm 





key = gEvent.message & charCodeMask; 
Do MenuCommand (MenuKkey (key)); 


Do_KeyDown überprüft in Zeile 5, ob das Command-Key-Flag 
des modifiers-Feldes des EventRecords gesetzt ist, indem dieses 
Feld mit der entsprechenden Maske mit Hilfe eines logischen 
"Und"s verknüpft wird. 

Hat der Benutzer eine Taste in Kombination mit der Befehlstaste 
getippt, so ist das Command-Key-Flag des modifiers-Feldes auf 
1 gesetzt und die Funktion Do_KeyDown reagiert, indem in Zei- 
le 7 zunächst der gedrückte Buchstabe aus dem message-Feld 
extrahiert wird. Dies wird durch ein logisches und mit der vor- 
definierten Konstanten charCodeMask erreicht, die den ASCII- 
Wert aus dem message-Feld herausfiltert. Die lokale Variable key, 
die jetzt den ASCII-Wert der gedrückten Taste enthält, wird in 
Zeile 8 an die Menu-Manager-Funktion MenuKey übergeben. 
Diese Funktion sucht in den Menüs nach einem Menüpunkt, der 
den gesuchten Menükurzbefehl hat, und gibt (wie MenuSelect) 
den gefundenen Menüpunkt bzw. die entsprechende Menu-ID 
im Ergebniswert dieser Funktion zurück. 

Dieser Ergebniswert von MenuKey wird dann in Zeile 9 an die 
Menübehandlungsroutine Do_MenuCommand übergeben, 
welche auf den ausgewählten Menüpunkt reagiert. 
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Das moditiers-Feld des 
EventRecords enthält 
die Information, ob bei 
der Betätigung der Taste 
die Befehlstaste 
gedrückt war. Die 
vordefinierte Maske 
cmdKey kann verwendet 
werden, um das 
entsprechende Bit des 
modifiers-Feldes 
auszumaskieren. 
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Controls 


Dieses Kapitel erläutert die Konzeption und den Einsatz der so- 
genannten "Controls". Zunächst wird ein genereller Überblick 
über die verschiedenen standardisierten Controls und ihre Aufgabe 
in bezug auf die Benutzerschnittstelle gegeben. 

Im zweiten Teil dieses Kapitels wird der Control-Manager, bzw. 
sein Zusammenwirken mit anderen Teilen der ToolBox, bespro- 
chen, der dritte Teil stellt dann die wichtigsten Datenstrukturen 
und Routinen dieses Managers vor. 

Die Anwendung des Control-Managers wird an dem Beispiel- 
Programm "MINIMUM4" demonstriert, welches auf dem voran- 
gegangenen Beispiel "MINIMUM3" aufbaut. Minimum4 bringt 
Scrollbars (eine Art von Controls) in die Applikation ein, um dem 
Benutzer die Möglichkeit des Scrollens zu geben. 

Controls bilden einen wichtigen Teil der Macintosh-Benutzer- 
oberfläche. Sie tragen durch ihr einheitliches Aussehen und ihre 
standardisierte Funktionalität erheblich zur homogenen Be- 
nutzeroberfläche des Macintosh bei. Da alle Programme diesel- 
ben Controls verwenden, sind (zumindest) die Bedienungs- 
elemente der Applikationen gleichartig zu benutzen. 


OÖ Radio-Button #1 [J] Check-Bos #1 
@) Radio-Button #2 RX Check-Box #2 





Es gibt eine Reihe standardisierter Controls, die für die verschie- 
densten Zwecke eingesetzt werden können: 
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Abb. 12-1 

Die verschiedenen 
Standard-Controls, wie 
sie vom Control- 
Manager zur Verfügung 
gestellt werden. 
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1. Buttons 





= Suchen und Ändern 


Diese Controls werden häufig in Dialogen ein- 








Suchen nach: DITL 


gesetzt. Ihre Funktionalität entspricht dem 








findern in: 





[ohne tet |] 


Drücken eines Knopfes und löst in der Regel 





eine direkte Aktion aus (gibt dem Programm den 





[_ suchen ] [_Andern ) [ Altes ändern ) 





Abb. 12-2 

Der "Suchen und 
Ändern'-Dialog eines 
Textverarbeitungs- 
Programms. 





Befehl, eine Aktion durchzuführen). Beispiels- 
weise bewirkt der "Alles ändern"-Button des 
"Suchen und Ändern"-Dialogs eines Textverarbeitungsprogramms 
eine direkte Aktion (das Suchen und Ersetzen des Textes). Buttons 
sollten immer in diesem Befehlszusammenhang eingesetzt wer- 
den, das Programm sollte durch direkte, sichtbare Aktionen auf 
das Drücken eines Buttons reagieren. 


2. Radio-Buttons 
Radio-Buttons werden (wie normale Buttons) 



































Abb. 12-3 

Die erweiterte Version 
des Dialogs verwendet 
Radio-Buttons, mit 
deren Hilfe das 
Verhalten des "Suchen 
und Ändern"-Befehls 
beeinflußt werden kann. 
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ED] Suchen und Ändern EZ R , . & 

7 | häufig in Dialogen eingesetzt. Ihre Funktiona- 

Suchen nach: |DITL | GEBE f 
RER a — lität in bezug auf das User-Interface entspricht 
sr den Stationstasten eines (alten) Radios; es ist 

r>uche 

© Sanze Wörter immer genau eine gedrückt (wird eine einge- 
@llortbastangtells schaltet, so werden alle anderen ausgeschaltet). 
(Su) fan) (sam) Wird ein Radio-Button ein- oder ausgeschaltet, 
so beeinflußt er die Arbeitsweise bestimmter 


Programmteile oder nachfolgender Aktionen. Das 
Drücken eines Radio-Buttons bewirkt also keine direkte Aktion, 
sondern beeinflußt die Arbeitsweise des Programms indirekt. Radio- 
Buttons sollten immer in Gruppen organisiert sein, d.h. daß ihre 
Zusammengehörigkeit durch Zusammenfassung in einem soge- 
nannten "Cluster" visualisiert werden sollte. Ein Cluster ist eine 
Umrahmung oder eine Überschrift der zusammengehörigen Radio- 
Buttons, welche als Titel die Beschreibung der Einstellungsmög- 
lichkeiten tragen sollte. Ein Beispiel für einen solchen Cluster 
wäre eine Gruppe von Radios, die in dem "Suchen und Ändern"- 
Dialog auftaucht, um die Art und Weise, in der Text gesucht und 
geändert wird, zu beeinflussen (siehe Abb. 12-3). Mit Hilfe der 
Radio-Buttons kann eingestellt werden, ob bei der Textsuche nur 
ganze Wörter gesucht werden, oder ob auch Teile eines Wortes 
erkannt werden sollen. Der Titel des gruppierenden Clusters 
entspricht dem Kontext der Einstellungen (Suchen), er ist so ge- 


wählt, daß er zusammen mit den Radios einen Satz bilden könn- 
te (z.B. "Suche ganze Wörter"). 


3. Check-Boxes 
Check-Boxes wirken (wie Radios) nur indi- 


A efejalige)S 


























PR % y EEE Suchen und findern 

rekt, mit ihnen können ebenfalls Optionen 

2 ‚ i Suchen nach: [pırı | 
für nachfolgende Aktionen oder Einstel- | „uaern in: foot 
lungen für bestimmte Programmteile ge- 

Suche 

macht werden. Im Unterschied zu Radio- E Ganze Wörter 
Buttons können Check-Boxes unabhängig er nn 
voneinander ein- und ausgeschaltet werden. EIIRERSCHBIENER DREHEN 
Sie werden daher auch häufig zum Ein/ (_Sucnen ) (_Andern ) (Altes ändern ) 





Ausschalten einer Option verwendet, Radi- 

os hingegen zum Umschalten zwischen verschiedenen, einander 
ausschließenden Optionen. Ein Beispiel für eine Check-Box ist 
die Option im Suchen und Ändern-Dialog, mit der man bestim- 
men kann, ob bei der Suche die Groß- und Kleinschreibung be- 
achtet werden soll. Auch Check-Boxes können durch einen Cluster 
zu einer Einheit zusammengefaßt werden, die sich mit einem 
bestimmten Thema befaßt. Ein solcher "Check-Box-Cluster" soll- 
te dann ausschließlich Check-Boxes enthalten (nicht mit Radio- 
Buttons oder anderen Elementen gemischt werden). 


4. Scrollbars 

Ein Scrollbar besteht aus mehreren Teilen, die jeweils eigene 
Funktionalitäten haben (Pfeil nach oben, Pfeil nach unten etc). 
Der Thumb ("Fahrstuhl") eines Scrollbars ist der sogenannte In- 
dikator, er zeigt den Wert des Controls an. Scrollbars werden in 
der Regel eingesetzt, um dem Benutzer das Verschieben einer 
Grafik zu ermöglichen, sie können aber auch unabhängig von 
dieser Funktionalität eingesetzt werden (etwa in Dialogen zum 
Einstellen eines Wertes). Ist der Scrollbar mit einer Grafik ver- 
bunden, so zeigt er die Position des sichtbaren Bereiches inner- 
halb der Gesamtgrafik an. Wird der Thumb verschoben, so ver- 
schiebt sich die verbundene Grafik. 





Abb. 12-4 

Diese Version des 
"Suchen und Ändern"- 
Dialogs enthält eine 
zusätzliche Check-Box. 





SIE Minimum FE 








Abb. 12-5 
Die Scrollbars eines 
Fensters. 
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CDEFs (Control - 
Definition-Functions) 
sind für die Darstellung 
und Verwaltung von 
Controls zuständig. 


Um einen neuen Control 
zu erzeugen, verwendet 
der Control-Manager 
eine Resource vom Typ 
'CNTL‘. 


Abb. 12-6 

Die verschiedenen 
Aktivierungszustände 
der Standard-Controls. 


Button 
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Der Control-Manager 


Der Control-Manager ist für die Verwaltung der Controls zu- 
ständig. Er setzt bei der Erzeugung und bei der Darstellung der 
Controls auf dem Resource-Manager bzw. QuickDraw auf. Die 
grafische Darstellung der Controls wird von sogenannten "CDEF"s 
("Control Definition Functions") übernommen. Diese CDEFs sind 
(wie WDEFs) eigenständige Code-Resources, die jeweils für eine 
bestimmte Control-Art zuständig sind. So existiert beispielsweise 
eine 'CDEF'-Resource im System, die für Buttons zuständig ist, 
eine andere kümmert sich um die Radio-Buttons. 

Die Erzeugung eines Controls basiert auf einer 'CNTL'-Resource. 
Wenn ein neuer Control erzeugt werden soll, so übergibt das 
Programm dem Control-Manager die Resource-ID einer 'CNTL'- 
Resource. Der Control-Manager erzeugt den neuen Control dann 
basierend auf den Informationen, die sich in diesem Control- 
Template befinden. 


Ein Control befindet sich immer in einem bestimmten Zustand. 
Dieser Zustand wird durch die grafische Darstellung des 
Controls visualisiert und kann durch die entsprechenden 
Control-Manager-Routinen beeinflußt werden. Ein Control 
kann sich in einem der folgenden Zustände befinden: 








DiCheck Bon Radio Button [ Button ELETIS Enabled 
Dtnerck-Bon ORadio-Butten | Button Kal 9 Disabled 








[Check Bon Radio Button ET ALTES Highlighted 


1. Aktiv (enabled) 
Ein aktiver Control wird normal dargestellt, d.h. er ist sichtbar 
und kann durch einen Mausklick betätigt werden. 


2. Inaktiv (disabled) 

Ein inaktiver Control ist "ausgegraut" (grau dargestellt) und kann 
nicht betätigt werden. Wenn die Funktionalität eines bestimmten 
Controls derzeit nicht verfügbar ist, so deaktiviert das Programm 
diesen Control, um den Benutzer davon zu informieren. Ändert 


12.2 Routinen und 


Datenstrukturen 





sich der Programmstatus, so daß die mit diesem Control ver- 
bundene Funktionalität wieder zur Verfügung steht, dann wird 
der Control wieder aktiviert, und der Benutzer kann ihn betäti- 
gen. 


3. Hervorgehoben (highlighted) 

Wenn der Benutzer mit der Maus auf einen aktiven Control klickt, GENE 
so wird dieser hervorgehoben, solange der Benutzer die Maustaste 

festhält. Je nach Control wird eine andere visuelle Aktion 
durchgeführt, um dem Benutzer das entsprechende "Gefühl" für 

die Benutzung des Controls zu geben. Ein gedrückter Button 

simuliert beispielsweise das "Drücken", indem er invertiert wird, 

ein Radio befindet sich in einer Zwischenstufe, bevor er beim 

Loslassen der Maustaste ausgelöst wird. 


Ein Control hat neben seinem Zustand auch immer 











einen aktuellen, einen minimalen und einen maximalen en 

Wert. Der aktuelle Wert befindet sich immer zwischen PER: 

dem minimalen und dem maximalen Wert, die prak- 

tisch die Grenzen für den aktuellen Wert darstellen. 

Bei einem Radio-Button oder einer Check-Box ent- 

spricht der aktuelle Wert immer dem minimalen (0) 

oder dem maximalen Wert (1). Bei einem Scrollbar gibt r 
es zwischen dem minimalen (beliebig) und dem ma- 2 


ximalen Wert (ebenfalls beliebig) auch Zwischenwerte, 

die jeweils der Position des Thumbs entsprechen. VE ENHIRT: 

Der aktuelle Wert eines Controls wird durch seine Max @Radio-Button 1 

grafische Darstellung visualisiert. Wird dieser Wert 

verändert, so paßt der Control sein Aussehen an die veränderte Abb. 12-7 

Situation an (ein Radio-Button oder eine Check-Box wird ein- Die verschiedenen 

oder ausgeschaltet, ein Scrollbar verschiebt den Thumb). Werte bzw. die grafische 
Darstellung dieser Werte 
durch Controls. 

12.2 Routinen und Datenstrukturen 


Der Control-Manager verwendet (wie beschrieben) eine bestimmte 
Art von Resources, um einen Control zu erzeugen. Diese 'CNTL'- 
Resources beinhalten Informationen über die Art des Controls, 
seine Position und die voreingestellten Werte. Soll ein Control 
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Eine 'GNTL'-Resource 
enthält Informationen 
über einen Control 
(Position, Größe, 
voreingestellte Werte 
etc.). 


Abb. 12-8 

Die Grafik visualisiert 
den Control, welcher mit 
der oben definierten 
'CNTL'-Resource 
erzeugt werden kann. 


erzeugt werden, so übergibt ein Macintosh-Programm die Re- 
source-ID einer 'CNTL'-Resource an den Control-Manager. Der 
Control-Manager lädt diese Resource dann mit Hilfe des Resource- 
Managers und erzeugt auf der Grundlage dieses Control-Templates 
einen neuen Control, der dann in einem Fenster installiert wird. 
Eine für die Erzeugung eines Controls benötigte 'CNTL'-Resource 
ist wie folgt aufgebaut: 


1: resource 'CNTL' (129) { 

2 {0, 0, 100, 16}, /* Rect */ 
3 10; /* Value x) 
4: visible, /* visible ?_ */ 
5: 100, /* Max %) 
6: 0, /* Min x/ 
7 scrollBarProc, /* CDEF x/ 
8 0; /* RefCon “/ 
9 wm /* Title */ 
10: }; 





100,16 


Diese 'CNTL'-Resource definiert einen Scrollbar. Sie beginnt in 
Zeile 2 mit der Spezifikation des umschließenden Rechtecks des 
Controls (in lokalen Koordinaten des Fensters). 

Zeile 3 spezifiziert den initialen Wert des Controls. Hier wird 
dieser Wert auf 10 gesetzt, der Scrollbar-Thumb ist damit etwas 
von seiner Ursprungsposition verschoben. 

In Zeile 4 wird dem Control-Manager mitgeteilt, daß der Control 
initial sichtbar sein soll, indem die vordefinierte Konstante visible 
verwendet wird. 

Zeile 5 und Zeile 6 geben den maximalen bzw. den minimalen 
Wert des Scrollbars an. Hier wird spezifiziert, daß der Scrollbar- 
Thumb (der initial den Wert 10 hat), den Wert 100 bekommt, wenn 
er ganz nach rechts geschoben ist und den Wert 0 erhält, wenn er 
ganz links liegt. 
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Zeile 7 spezifiziert, daß es sich hier um einen Scrollbar handelt, 
indem die vordefinierte Konstante scrollBarProc verwendet wird. 
Diese Konstante ist der Hinweis für den Control-Manager, wel- 
che Control-Definition-Function verwendet werden soll, um den 
Control darzustellen. 

Zeile 8 enthält das RefCon des Controls. Dieses RefCon (ein long) 
kann beliebige Werte enthalten und wird oft benutzt, um die 
Controls durchzunumerieren und so voneinander unterscheiden 
zu können. 

Da Scrollbars keinen Text enthalten, ist der String in Zeile 9 leer. 
Bei Radio-Buttons oder Check-Boxes definiert er den Titel des 
Controls (erscheint rechts neben dem Contro)). 


Ist ein Control geladen und in einem Fenster installiert, so wird 
der Control mit einer Datenstruktur von Typ ControlRecord bzw. 
einem ControlHandle verwaltet. Ein ControlRecord enthält die 
Informationen über den Control (den Status, die Position, den 
aktuellen Wert etc.) und ist wie folgt aufgebaut: 


1: struct ControlRecord { Der Control-Manager 
2 struct ControlRecord **nextControl; verwendet eine Struktur 
3 windowPtr contrlOwner; vom Typ GontrolRecord, 
4: Rect contrlRect; i 
; 5 um Controls zur Laufzeit 

9 unsigned char contrlVis; . 5 
6 unsigned char contrlHilite; zu verwalten. Sie enthält 
7 short contrlValue; im wesentlichen die 
8: short contrlMin; Informationen, welche 
9: short contrlMax; in der 'CNTL'-Resource 
10: Handle contrlDefProc; definiert wurden. 

115 Handle contrlData; 

12: ProcPtr contrlAction; 

13:5 long contriRfCon; 

14: Str255 contrlTitle; 

9: 45 


16: 

17: typedef struct ControlRecord ControlRecord; 

18: typedef ControlRecord *ControlPtr, 
**ControlHandle; 


Jedes Fenster enthält die Wurzel einer verketteten Control-Liste, 
welche die Controls enthält, die in dem Fenster installiert sind. 
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Jeder ControlRecord enthält in dem Feld nextControl den Handle 
auf das nächste Element dieser Control-Liste. 

Das Feld contrlOwner zeigt auf das Fenster, in dem der Control 
installiert ist (zu dem er gehört). 

Das umschließende Rechteck des Controls ist in dem Feld 
contrlRect enthalten. 

Das Feld contrlVis spezifiziert, ob der Control sichtbar (255) oder 
unsichtbar (0) ist. 

An contrlHilite kann abgelesen werden, in welchem der folgen- 
den Aktivierungs-Zustände sich der Control befindet: 


Obedeutet, daß er aktiv (enabled) ist. Dieser Wert entspricht damit 
dem Normalzustand des Controls. 


Ein Wert zwischen 1 und 253 bedeutet, daß ein bestimmter Teil 
des Controls highlighted ist (der Benutzer hat auf den Control 
geklickt). Der Wert dieses Feldes gibt dann Auskunft über den 
hervorgehobenen Teil des Controls (z.B. "Pfeil nach oben" oder 
"Pfeil nach unten" bei einem Scrollbar). 


255 bedeutet, daß der Control inaktiv (ausgegraut) ist. 


Der aktuelle Wert des Controls kann an dem contrlValue-Feld 
abgelesen werden. Bei einem Scrollbar enthält dieses Feld den 
aktuellen Wert des Thumbs, bei einem Radio-Button oder einer 
Check-Box gibt dieses Feld Auskunft darüber, ob der Control 
ein- oder ausgeschaltet ist (1 oder 0). 

Der minimale bzw. maximale Wert, den der Control annehmen 
kann, wird durch die Felder contrlMin und contrlMax spezifi- 
ziert. 

Das Feld contrlDefProc enthält den Handle auf die geladene 
Control-Definition-Function (CDEF), die für das Zeichnen dieses 
Controls zuständig ist. Das nachfolgende Feld (contrlData) wird 
von der Control-Definition-Function dazu verwendet, zusätzlich 
zu den im ControlRecord enthaltenen Daten eigene Informationen 
abzulegen. 

Das Feld contrlAction enthält einen Funktions-Pointer auf eine 
Routine, die für dieStandard-Funktionalität des Controls zuständig 
ist. Diese Standard-Funktionalität ist beispielsweise das Invertieren 
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des Controls, wenn der Benutzer auf einen Button klickt. Siekann 
durch eigene Funktionalitäten überlagert werden, indem hier die 
Adresse einer selbstgeschriebenen Routine eingetragen wird. Diese 
Routine wird dann aufgerufen, wenn der Benutzer in den Control 
klickt, und kann zusätzliche Aktionen durchführen. 

Das Feld contrlRfCon steht uns Programmierern zur freien Ver- 
fügung. Dieses Feld wird oft dazu verwendet, die Controls eines 
Fensters oder Dialogs durchzunumerieren und so voneinander 
unterscheiden zu können. 

Das letzte Feld des ControlRecords (contrITitle) enthält den Titel 
des Controls. Beieinem Radio-Button oder einer Check-Box enthält 
dieses Feld den Text, der neben dem Control erscheint. 


Um ein Control zu erzeugen, stellt der Control-Manager die _GetlewControl 
Funktion GetNewControl zur Verfügung. Diese Funktion erzeugt 

das neue Control auf der Grundlage einer 'CNTL'-Resource und 

installiert es in einem Fenster. 


pascal ControlHandle GetNewControl ( 
short controlID, 
WindowPtr owner); 


GetNewControl lädt die'CNTL'-Resource, die durch die Resource- 
ID controlID spezifiziert wird, in den Speicher und erzeugt auf 
deren Grundlage ein neues Control. Das Fenster, in dem der neue 
Control installiert werden soll, wird durch den Parameter owner 
spezifiziert. Der neue Control wird in die Control-Liste dieses 
Fensters eingetragen und "gehört" damit zu diesem Fenster. 
GetNewControl gibt den Handle auf den neu erzeugten Control 
als Ergebniswert an das Programm zurück. Ein solcher Control- 
Handle wird von den übrigen Control-Manager-Funktionen als 
Eingabeparameter verlangt, um zu spezifizieren, mit welchem 
Control diese Funktionen arbeiten sollen. 


Wenn die Main-Event-Loop eines Macintosh-Programms fest- FindControl 

stellt, daß der Benutzer in den Inhalt eines Fensters geklickt hat 

(FindWindow hat den Wert inContent zurückgegeben), so ruft 

das Programm zunächst die Funktion FindControl auf, um fest- 

zustellen, ob der Klick eventuell in einem Control des Fensters 

gelegen hat. Anhand des Ergebniswertes dieser Funktion ent- 251 
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Bevor FindControl 
aufgerufen wird, 
müssen die Koordinaten 
des Mausklicks mit Hilfe 
der Funktion 
GlobalToLocal auf das 
lokale Koordinaten- 
system des Fensters 
umgerechnet werden. 


scheidet es dann, ob der Benutzer in den Darstellungsbereich 
oder z.B. auf die Scrollbars eines Fensters geklickt hat und ver- 
zweigt anschließend in die entsprechenden Behandlungsroutinen. 


pascal short FindControl ( 


Point thePoint, 
WwindowPtr theWindow, 
ControlHandle *theControl); 


FindControl erwartet (wie FindWindow) die Koordinaten des 
Mausklicks in dem Parameter thePoint. Im Gegensatz zu Find- 
Window müssen die an FindControl übergebenen Mauskoordi- 
naten auf das lokale Koordinatensystem des Fensters bezogen 
sein. Die mit dem MouseDown-Event mitgelieferten Koordina- 
ten müssen daher zunächst mit der QuickDraw-Funktion 
GlobalToLocal auf das lokale Koordinatensystem des Fensters 
umgerechnet werden. 

Das Fenster, in dem der Mausklick lag, wird durch den Para- 
meter theWindow spezifiziert. Hier wird üblicherweise der 
WindowPitr übergeben, den die Window-Manager-Funktion 
FindWindow zurückgegeben hat (das getroffene Fenster). 
Wenn die Funktion FindControl feststellt, daß der Mausklick in 
einem Control gelegen hat, so gibt sie den "getroffenen" Control 
in der Variablen, deren Adresse bei theControl übergeben wird, 
zurück. Dieser Parameter ist damit neben dem eigentlichen Er- 
gebnis der Funktion ein zweiter Ergebniswert. 

Der eigentliche Ergebniswert von FindControl gibt an, ob ein 
Control getroffen wurde (Ergebniswert ungleich 0). Wenn der 
Mausklick in einem Control lag, so spezifiziert der Ergebniswert, 
in welchem Bereich des Controls der Mausklick gelegen hat. Bei 
einem Scrollbar existieren beispielsweise fünf verschiedene Be- 
reiche, die vom Benutzer angeklickt werden können (z.B. Pfeil 
nach oben oder Pfeil nach unten). Der Ergebniswert von Find- 
Control kann mit den folgenden vordefinierten Konstanten ver- 
glichen werden, um herauszufinden, wie auf den Mausklick rea- 
giert werden soll: 


#define inButton 10 


Der Benutzer hat in einen Button geklickt. Das Programm sollte 
die Funktion TrackControl aufrufen (wird später erläutert), die 
dann den Button (jenach Mausposition) invertiert. Anschließend 
sollte das Programm die mit diesem Button verbundene Aktion 
durchführen. 


#define inCheckBox 11 


Der Benutzer hat in eine Check-Box oder in einen Radio-Button 
geklickt. Auch hier sollte die Funktion TrackControl aufgerufen 
werden, um den Control hervorzuheben. 


#define inUpButton 20 


Der Benutzer hat in den "Pfeil nach Oben" eines Scrollbars ge- 
klickt. Das Programm sollte die Funktion TrackControl aufrufen 
und dieser Funktion eine sogenannte "Call Back Routine" über- 
geben, die für das Scrollen der verbundenen Grafik verantwortlich 
ist. Diese Routine wird dann von TrackControl solange aufgerufen, 
bis der Benutzer die Maustaste losläßt. 

Der Mechanismus einer "Call-Back-Routine" wird später genauer 
beschrieben. 


#define inDownButton 21 


Der "Pfeil nach Unten" eines Scrollbars wurde getroffen. Das 
Programm reagiert wie bei inUpButton, die "Call-Back-Routine" 
scrollt die Grafik jedoch in entgegengesetzter Richtung. 


#define inPageUp 22 


Der Benutzer hat in den Bereich eines Scrollbars geklickt, der die 
Grafik seitenweise scrollen ("umblättern") soll. Die Reaktion des 
Programms ist vergleichbar mit der Reaktion auf inDownButton 
bzw. inUpButton, nur daß hier um größere Bereiche gescrollt 
wird. 


#define inPageDown 23 
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Abb. 12-9 

TrackControl übernimmt 
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nach Mausposition) in 
den entsprechenden 
Zustand. 
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Es soll ebenfalls umgeblättert werden, nur soll die Grafik bei diesem 
Teil des Scrollbars in die entgegengesetzte Richtung verschoben 
werden. Die Reaktion entspricht ansonsten der von inPageUp. 


#define inThumb 24 


Der Benutzer möchte zu einem bestimmten Bereich der Grafik 
"springen". Das Programm sollte die Funktion TrackControl 
aufrufen, ohne eine "Call-Back-Routine" zu spezifizieren. Kehrt 
TrackControl zurück, so sollte die Grafik um die Differenz des 
alten und neuen Wertes des Scrollbars gescrollt werden. 


In der Regel wird die Funktion TrackControl aufgerufen, nach- 
dem FindControl festgestellt hat, daß der Klick in einem Control 
liegt. TrackControl sorgt dafür, daß der Control hervorgehoben 
wird, wenn die Mausposition innerhalb des Controls liegt, so- 
lange der Benutzer die Maustaste gedrückt hält. Diese Funktion 
gibt dem Benutzer "das Gefühl", den Control zu "drücken" (sie- 
he Abb. 12-9). 


pascal short TrackControl ( 


ControlHandle theControl, 
Point thePoint, 
ProcPtr actionProc); 


Der Control, der durch den Mausklick getroffen wurde, wird 
durch den Parameter theControl angegeben und entspricht in der 
Regel dem von FindControl zurückgegebenen ControlHandle. 
Die Startposition des Mausklicks (in lokalen Koordinaten des 
Fensters) wird durch den Point thePoint spezifiziert. 
TrackControl übernimmt die Kontrolle und folgt der Mausposition, 
wobei der Control jeweils in den entsprechenden Zustand versetzt 
wird. Wenn die Mausposition innerhalb des getroffenen Control- 
Teils liegt, so wird dieser hervorgehoben (highlighted), liegt die 
Position außerhalb, so wird die Hervorhebung zurückgenom- 
men. 

Während FindControl die Kontrolle übernommen hat, ruft es 
ständig die Funktion auf, deren Adresse bei actionProc überge- 
ben wird. Wenn bei einem Klick in einen Scrollbar beispielswei- 
se der "Pfeil nach oben" getroffen wurde, so übergibt ein Macin- 


tosh-Programm anstelle des actionProc-Parameters die Adresse 
einer Routine, die dann wiederholt aufgerufen wird, solange der 
Benutzer die Maustaste gedrückt hält. Diese Call-Back-Routine 
ist dann dafür verantwortlich, die mit dem Scrollbar verbundene 
Grafik zu scrollen. 

Eine solche "Call-Back-Routine" muß wie folgt deklariert sein: 


pascal void MyScrollAction ( 
ControlHandle 
short 


theControl, 
partCode); 


Wenn TrackControl diese Funktion aufruft, wird der Control- 
Handle durch den Parameter theControl spezifiziert. Der Control- 
Teil, in dem sich die Mausposition befindet, wird durch den 
Parameter partCode spezifiziert (wie der Ergebniswert von 
FindControl). Eine solche "Call-Back-Routine" enthält üblicher- 
weise eine "switch"-Anweisung über den Parameter partCode, 
um festzustellen, wie sie reagieren muß (z.B. in welche Richtung 
gescrollt werden soll). 

Bei einfachen Controls (wie z.B. einem Radio oder einem Button) 
wird die Möglichkeit einer Call-Back-Routine selten verwendet, 
da keine Aktionen (außer den Control hervorzuheben) durchge- 
führt werden müssen, während der Benutzer die Maustaste ge- 
drückt hält. Erst wenn der Benutzer die Maustaste losläßt, rea- 
giert das Programm mit einer entsprechenden Aktion. 

Bei einfachen Controls wird daher nur der Ergebniswert der 
Funktion TrackControl inspiziert, um festzustellen, ob der Benutzer 
die Maustaste innerhalb des Controls losgelassen hat und die 
Aktion (z.B. Einschalten des Radios) durchführen will. Track- 
Control gibt als Ergebniswert (wie FindControl) den Bereich des 
Controls zurück, in dem sich die Mausposition befand, als die 
Maustaste losgelassen wurde. Ist dieser Ergebniswert gleich 0, 
so hat der Benutzer die Maustaste außerhalb des Controls los- 
gelassen und möchte die Aktion nicht durchführen. Ist dieser 
Wert ungleich 0, so soll die Aktion durchgeführt werden. 


Um den maximalen Wert, den ein Control annehmen kann, zu 
verändern, steht die Funktion SetCtlMax zur Verfügung. Wird 
der Thumb eines Scrollbars beispielsweise ganz nach rechts oder 
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ganz nach unten gezogen, so bekommt der Control diesen maxi- 
malen Wert. 


pascal void SetCtlMax ( 
ControlHandle theControl, 
short maxValue); 


Der Control, dessen Maximum gesetzt werden soll, wird durch 
den übergebenen ControlHandle, der neue maximale Wert wird 
durch den Parameter maxValue spezifiziert. 


Die korrespondierende Funktion zu SetCtlMax ist SetCtlMin. Diese 
Funktion arbeitet wie SetCtlMax, ändert jedoch den minimalen 
Wert, den der Control annehmen kann. Ist beispielsweise der 
Thumb eines Scrollbars ganz links oder ganz oben, so erhält der 
Control diesen minimalen Wert. 


pascal void SetCtlMin ( 
ControlHandle theControl, 
short minValue); 


Der Control, dessen minimaler Wert verändert werden soll, wird 
durch den ControlHandle theControl, der neue minimale Wert 
wird durch den Parameter minValue spezifiziert. 


Soll der aktuelle Wert eines Controls verändert werden, so steht 
die Funktion SetCtlValue zur Verfügung. Mit dieser Funktion 
kann ein Radio-Button oder eine Check-Box ein- und ausgeschaltet 
werden, indem der entsprechende Wert (0 oder 1) übergeben wird. 
Bei einem Scrollbar kann diese Funktion dazu verwendet wer- 
den, die Position des Thumbs zu verändern. 


pascal void SetCtlValue ( 
ControlHandle theControl, 
short theValue); 


Der Control, dessen aktueller Wert verändert werden soll, wird 
durch den ControlHandle theControl spezifiziert. Der neue Wert 
des Controls wird durch den Parameter theValue angegeben. 
Dieser Wert entspricht dem neuen Zustand eines Radio-Buttons 
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oder einer Check-Box bzw. der Position des Thumbs bei einem 
Scrollbar. Ein Aufruf dieser Funktion ändert nicht nur den internen 
Wert eines Controls, sondern führt auch zum Neuzeichnen des 
Controls. 


Um den aktuellen Wert eines Controls abzufragen, steht die GetCtlValue 
Funktion GetCtlValue zur Verfügung. Mit ihrer Hilfe kann bei- 

spielsweise die aktuelle Position eines Scrollbar-Thumbs abgefragt 

werden oder herausgefunden werden, ob ein Radio-Button ein- 

oder ausgeschaltet ist. 


pascal short GetCtlValue ( 
ControlHandle theControl); 


GetCtlValue gibt den aktuellen Wert des Controls, der durch den 
ControlHandle theControl spezifiziert wird, als Ergebniswert an 
das Programm zurück. 


Soll ein Control versteckt werden, so kann die Funktion Hide- HideControl 
Control verwendet werden. Diese Funktion wird meist dazu 

verwendet, die Scrollbars unsichtbar zu machen, wenn einFen- = Minimum EBENE 
ster in den Hintergrund geschickt wird (bei einem DeActivate- P 





Event für das Fenster). 

Um die einfache Benutzung der Macintosh-Oberfläche zu erhalten, 
sollte man (außer bei Scrollbars) auf das Verstecken von Controls 
verzichten, und stattdessen nicht verfügbare Controls durch 
"Ausgrauen" (Deaktivieren) kennzeichnen. 








pascal void HideControl ( 
ControlHandle theControl); 





Der Control, welcher versteckt werden soll, wird durch den 

ControlHandle theControl spezifiziert. HideControl löscht den Abb. 12-11 

Teil des Fensters, der durch den Control belegt wird und generiert Bei einem aktiven 

einen Update-Event für diesen Bereich. Fenster sind die 
Scrollbars sichtbar. Ist 

Das Gegenstück zu HideControl ist die Funktion ShowControl. das Fenster im Hinter- 

Diese Funktion macht einen (vormals versteckten) Control wie- grund, so werden sie 

der sichtbar. Sie wird meist als Reaktion aufeinen Activate-Event versteckt. 
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für ein Fenster aufgerufen, um die Scrollbars dieses Fensters wieder 
sichtbar zu machen. 


pascal void ShowControl ( 
ControlHandle theControl); 


ShowControl macht den Control, der durch den ControlHandle 
theControl spezifiziert wird, wieder sichtbar und damit für den 
Benutzer zugänglich. 


Um den Status eines Controls zu verändern, steht die Funktion 
HiliteControl zur Verfügung. Mit ihrer Hilfe kann ein Control 
hervorgehoben, eine Hervorhebung aufgehoben, oder der Control 
disabled bzw. enabled werden. Da das Hervorheben eines Controls 
während des Mausklicks von TrackControl übernommen wird, 
verwendet man HiliteControl hauptsächlich, um einen Control 
zu deaktivieren bzw. zu aktivieren. 


pascal void HiliteControl ( 
ControlHandle theControl, 
short hiliteState); 


HiliteControl ändert den Status des Controls, der durch den 
ControlHandle theControl spezifiziert wird, auf den Status, der 
in dem Parameter hiliteState übergeben wird. Der Status eines 
Controls ist unabhängig von dessen Wert und bezieht sich nur auf 
das Erscheinungsbild des Controls. Die folgenden Werte kön- 
nen anstelle von hiliteState übergeben werden, um den Control 
zu aktivieren bzw. zu deaktivieren oder einen bestimmten Teil 
des Controls hervorzuheben: 


0 bedeutet, daß der Control aktiviert (enabled) wird. Dieser Wert 
versetzt den Control in seinen Normalzustand. Der Wert 0 wird 
dazu verwendet, um einen inaktiven Control zu aktivieren oder 
eine Hervorhebung aufzuheben. 


Ein Wert zwischen 1 und 253 entspricht einem bestimmten Teil 
des Controls. Dieser Teil des Controls (z.B. inUpButton bei einem 
Scrollbar) wird dann hervorgehoben (highlighted). Bei einem 
einfachen Control (z.B. einem Button) existieren keine Control- 





12.2 Routinen und 


Datenstrukturen 
Teile, daher wird ein solcher Control immer komplett hervorge- 


hoben (z.B. invertiert), wenn der Wert zwischen 1 und 253 liegt. 


255 bedeutet, daß der Control disabled werden soll. Er wird dann 
ausgegraut gezeichnet und steht dem Benutzer nicht mehr zur 
Verfügung. Dieser Wert wird verwendet, wenn der Control in 
einer bestimmten Programmsituation nicht verwendet werden 
kann. 


Um einen Control zu verschieben, stellt der Control-Manager MoveControl 
die Funktion MoveControl zur Verfügung. MoveControl wird 
hauptsächlich dazu verwendet, um die Scrollbars zu verschie- 

ben, nachdem die Fenstergröße geändert wurde (z.B. nach 
GrowWindow oder ZoomWindow). 


pascal void MoveControl ( 


ControlHandle theControl, 
short h, 
short v); 


Der Control, welcher verschoben werden soll, wird durch den 
Parameter theControl spezifiziert. Die neue horizontale bzw. 
vertikale Position des Controls wird durch die Parameter h bzw. 
vaangegeben. Diese Koordinaten entsprechen der linken oberen 
Ecke des Controls. 


Um die Größe eines Controls zu verändern, kann die Funktion _SizeControl 
SizeControl verwendet werden. Diese Funktion wird meist in 
Verbindung mit MoveControl verwendet, um die Höhe bzw. Breite 

der Scrollbars an eine neue Fenstergröße anzupassen. 


pascal void SizeControl ( 


ControlHandle theControl, 
short W, 
short h); 


Der Control, dessen Größe verändert werden soll, wird durch 
den Parameter theControl angegeben. Die Parameter w bzw. h 
spezifizieren die neue Breite bzw. Höhe des Controls. 
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DrawGControls 


Bei einem Update-Event für ein Fenster müssen die Controls dieses 
Fensters mit Hilfe der Funktion DrawControls neugezeichnet 
werden. DrawControls zeichnet sämtliche Controls eines Fensters 
neu, indem es die Control-Liste, die an diesem Fenster "hängt", 
durchläuft und jeden Control einzeln zeichnet. 


pascal void DrawControls (WindowPtr theWindow); 


Das Fenster, dessen Controls neugezeichnet werden sollen, wird 
bei einem Aufruf von DrawControls durch den WindowPtr 
theWindow spezifiziert. 


12.3 MINIMUM4 - Die Applikation bekommt Scrollbars 


Das Beispiel-Programm "MINIMUMA4" demonstriert die Ver- 
wendung von Controls anhand einer erweiterten Version von 
MINIMUMS3, welche in der Lage ist, die Grafik eines Fensters 
mit Hilfe von Scrollbars zu verschieben. 

Minimum4 bildet mit dieser Grundfunktionalität eines jeden 
Macintosh-Programms den Ausgangspunkt einer neuen Gene- 
ration von Beispiel-Programmen, die als Basis für komplexere 
Projekte verwendet werden können. 

Das Programm installiert in dem Fenster einen horizontalen und 
einen vertikalen Scrollbar und reagiert auf Mausklicks in die 
Scrollbars, indem die Grafik verschoben wird. Die Scrollbar- 
Verwaltung von Minimum& istso ausgerichtet, daß sieohne großen 
Aufwand an jeden Inhalt angepaßt werden kann; sie ist unabhängig 
von dem zu scrollenden Inhalt und kann daher auch für komplexere 
Projekte eingesetzt werden. Wird das Fenster vergrößert oder 
verkleinert, so werden die Scrollbars an die neue Größe des Fensters 
angepaßt. Bei dieser Anpassung wird auch darauf geachtet, daß 
durch das Vergrößern des Fensters eventuell die gesamte Grafik 
sichtbar werden kann, was zum Deaktivieren der Scrollbars führen 
soll. Wird das Fenster wieder verkleinert, so daß ein Teil der Grafik 
verdeckt wird, werden die Scrollbars wieder aktiviert. Wenn das 
Programm im Multifinder in den Hintergrund geschickt wird 
(DeActivate-Event), so reagiert es entsprechend der "Human 
Interface Guidelines", indem die Scrollbars versteckt werden. Bei 





12.3 MINIMUM4 
einem Activate-Event (Programm kommt nach vorne) werden 


die Scrollbars wieder sichtbar. 


Minimum“ basiert auf dem vorangegangen Beispiel Minimum3. 
Für die Verwaltung der Scrollbars sowie für die Funktionalität 
des Scrollens wurden die folgenden Routinen modifiziert bzw. 
neu in den Quelltext aufgenommen: 


1. Die Funktion Init_ToolBox wurde um die Initialisierung des 
Control-Managers erweitert. 


2. Make_Windows wurde so erweitert, daß der horizontale bzw. 
vertikale Scrollbar in dem neuen Fenster installiert wird. 


3. Die Funktion Do_MouseCommand wurde so erweitert, daß 
sie einen Mausklick in den Fensterinhalt erkennt und die Event- 
Behandlungsroutine Do_ContentClick aufruft. 


4. Do_ContentClick ist eine neue Funktion, die mit Hilfe von 
FindControl feststellt, ob der Mausklick in einem der beiden 
Scrollbars liegt. Falls der Benutzer in den Thumb eines Scrollbars 
geklickt hat, so wird die Funktion TrackControl aufgerufen, die 
dem Benutzer die Möglichkeit gibt, den Thumb zu verschieben. 
Anschließend ruft die Funktion Do_ContentClick die Scroll-Routi- 
ne Scroll_Graphics auf, um die Grafik zu scrollen. 

Wenn der Mausklick in einem der anderen Scrollbar-Bereiche 
(z.B. "Pfeil nach oben") liegt, so ruft Do_ContentClick TrackControl 
auf und übergibt die Adresse der "Call-Back-Routine" Scroll_Proc. 
TrackControl ruft diese Funktion dann solange auf, wie der Be- 
nutzer die Maustaste gedrückt hält. 


5. Die neue Funktion Scroll_Proc sorgt dafür, daß die Grafik ge- 
scrollt wird, solange der Benutzer die Maustaste gedrückt hält. 
Scroll_Proc entscheidet, in welche Richtung und um wieviel Punkte 
gescrollt werden soll, und ruft die Funktion Do_Scroll auf. 


6. Do_Scroll ist eine neue Funktion, die das Scrollen der Grafik 
und das Verschieben des Scrollbar-Thumbs organisiert. Diese 


Funktion faßt zwei Aktionen zusammen: Erstens sorgt Do_Scroll 
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dafür, daß der Scrollbar-Thumb verschoben wird, indem die 
Funktion Scroll_Scrollbars aufgerufen wird. Zweitens ruft 
Do_Scroll die Funktion Scroll_Graphics auf, die für das Verschie- 
ben der Grafik sorgt. 


7. Die neue Funktion Scroll_Scrollbar sorgt mit einem Aufruf von 
SetCtlValue dafür, daß sich der Scrollbar-Thumb um den ge- 
wünschten Bereich verschiebt, um den Thumb mit der Grafik zu 
synchronisieren. Scroll_Scrollbar ist gleichzeitig eine "Kontroll- 
funktion". Ist der Wert, um den gescrollt werden, soll zu groß, so 
verhindert Scroll_Scrollbar, daß die Grafik zu weit gescrollt wird, 
indem sie den Ergebniswert der Funktion verändert. Dieser 
Ergebniswert wird von Do_Scroll dazu verwendet, Scroll_Graphics 
mitzuteilen, um wieviele Punkte die Grafik gescrollt werden soll. 
Auf diese Weise bildet die minimale bzw. maximale Position des 
Scrollbar-Thumbs die Grenze des Scroll-Bereiches. 


8. Scroll_Graphics ist eine neue Funktion, die von Do_Scrollund 
Do_ContentClick aufgerufen wird, um die Grafik des Fensters 
zu verschieben. Do_Scroll benutzt die QuickDraw-Funktion 
ScrollRect, um die Grafik zu verschieben, und sorgt anschließend 
dafür, daß die freigelegten Bereiche neugezeichnet werden. 


9. Die Funktionen Do_GrowWindow und Do_ZoomWindow 
wurden um einen Aufruf der neuen Funktion Adjust_Scrollbars 
erweitert, damit sich die Scrollbars an eine neue Fenstergröße 
anpassen können. 


10. Adjust_Scrollbars ist eine neue Funktion, die die Position und 
Größe der Scrollbars an eine neue Fenstergröße anpaßt. Nach- 
dem die Scrollbars verschoben und vergrößert bzw. verkleinert 
wurden, wird die Funktion Recalc_Scrollbars aufgerufen, um die 
veränderte Relation zwischen den verdeckten Teilen der Grafik 
und der Fenstergröße zu überprüfen. 


11. Die neue Funktion Recalc_Scrollbars vergleicht die Größe der 
Grafik mit der neuen Fenstergröße. Ist das Fenster kleiner als die 
Grafik, so wird der vertikale bzw. der horizontale Scrollbar akti- 
viert. Recalc_Scrollbars berechnet auch den verdeckten Bereich 
der Grafik und setzt die maximalen Werte der Scrollbars, so daß 


eine eindeutige Beziehung zwischen den Scrollbars und dem 
verdeckten Bereich hergestellt wird. Ist die gesamte Grafik 
sichtbar, so werden die Scrollbars deaktiviert. 


12. Die Funktion Do_Update wurde so erweitert, daß sie bei ei- 
nem Update-Event die Scrollbars des Fensters neu zeichnet. 


13. Set_DrawingEnv wurde so verändert, daß der Ursprung des 
Koordinatensystems mit der verschobenen Grafik in Einklang 
gebracht wird. Set_DrawingEnv wird von Do_Update aufgeru- 
fen, bevor die Zeichenroutine Draw_Graphics aufgerufen wird, 
so daß die Verschiebung des Ursprungs dazu führt, daß bei ei- 
nem Update-Event an der richtigen Stelle gezeichnet wird. 


14. Die veränderte Version von Set_WindowEnv sorgt dafür, daß 
der Ursprung des Koordinatensystems wieder auf den alten 
Nullpunkt gesetzt wird, und hebt dadurch die Auswirkungen 
von Set_DrawingEnv auf. Dies wird nötig, da auch die Scrollbars 
im Koordinatensystem des Fensters definiert sind und verscho- 
ben werden, wenn sich der Ursprung des Koordinatensystems 
ändert. Diese Funktion wird daher direkt nach dem Zeichnen 
der Grafik (Draw_Graphics) aufgerufen, um das Koordinaten- 
system wieder in den Normalzustand zu versetzen. 


15. Die Funktion Do_Activate wurde so erweitert, daß sie bei ei- 
nem DeActivate-Event dafür sorgt, daß die Scrollbars versteckt 
werden (HideControl), bzw. bei einem Activate-Event wieder 
gezeigt werden (ShowControl). 
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Abb. 12-13 

Die Grafik zeigt den 
veränderten Kontrollfluß 
in Minimum4 im 
Vergleich zum vorange- 
gangenen Beispiel 
Minimum3. Die 
veränderten bzw. neuen 
Routinen sind hervorge- 
hoben. 
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Im Nachfolgenden werden die geänderten bzw. die neuen Rou- 
tinen von Minimum4 analysiert: 


Zunächst wird eine neue Interface-Datei benötigt, um mit den 
Routinen und Datenstrukturen des Control-Managers arbeiten 
zu können. Diese Interface-Datei wird mit Hilfe des #include- 
Statements in Zeile 8 in den Quelltext eingebunden. 


Die Interface-Datei 1: #include <Types.h> 
"Controls.h' enthält die 2: #include <QuickDraw.h> 
Deklaration der 3: #include <Fonts.h> 
4: #include <Windows.h> 
Datonstzukturen und 5: #include <Events.h> 
Routinen des Control- 6: #include <ToolUtils.h> 
Managers. 7: #include <Menus.h> 
8: #include <Controls.h> 
Minimum4 verwendet weiterhin zwei neue globale Variablen, 
um den horizontalen bzw. den vertikalen Scrollbar zu verwalten. 
Zwei neue globale 1: ControlHandle gHorizScrollbar, 
Variablen. 2: gVertScrollbar; 
Die veränderte Version der Funktion Make Window: 
Make_Window installiert 1: void Make Window (void) 
jetzt zwei Scrollbars in 22 Ä 
dem neu erzeugten 3 gWindow = GetNewwWindow (128, NULL, 
Fönster (windowPtr) -1); 
4: SetPort (gWindow); 
5% gVertScrollbar = GetNewControl (128, 
gWindow) ; 
6: gHorizScrollbar = GetNewControl (129, 
qWindow) ; 
Te} 


Make_Window erzeugt in den Zeilen 5 und 6 die beiden Scrollbars 
und installiert sie in dem durch GetNewWindow erzeugten 
Fenster. Um die Scrollbars zu erzeugen, wird die Funktion 
GetNewControl aufgerufen und die Resource-ID einer 'CNTL'- 
Resource bzw. ein Pointer auf das Fenster übergeben. GetNew- 


Ai Control lädt die 'CNTL'-Resource mit der entsprechenden Re- 


source-ID und generiert einen neuen Control auf der Grundlage 
dieses Control-Templates. Dieser Control wird im Fenster installiert 
und der Handle auf den ControlRecord an das Programm zu- 
rückgegeben. 


Neue Resources: 


1: resource 'CNTL' (128) { /* Vertikal *“/ 
2 {-1, 385, 286, 401}, /* Rect *“/ 
3: 0, /* Value %/ 
4: visible, /* Visible ? %/ 
5: 0, /* Max x/ 
6 0, /* Min */ 
7 scrollBarProc, /* CDEF */ 
8: 0, /* RefCon */ 
9: un /* Title x/ 
10: }; 

11: 

12: resource 'CNTL' (128) { /* Horizontal */ 
13: {285, -1, 301, 386}, /* Rect x/ 
14: 0, /* Value */ 
19% visible, /* Visible ? x“/ 
16: 0, /* Max */ 
17: 0, /* Min */ 
18: scrollBarProc, /* CDEF x/ 
19: 0, /* RefCon *“/ 
20: u /* Title */ 
21,7% 


Die Zeilen 1 bis 10 definieren den vertikalen, die Zeilen 12 bis 21 
den horizontalen Scrollbar. Die initiale Position der Scrollbars 
entspricht der Position, die sie bei der ursprünglichen Fenster- 
größe einnehmen sollen. Die Scrollbars sind so positioniert, daß 
sich die Ränder der Scrollbars mit dem Fensterrahmen überlap- 
pen. Dies wird nötig, da auch die Scrollbars einen Rahmenbesitzen 
und eine doppelte Umrahmung vermieden werden soll. Die 
überlappende Positionierung wird an der vertikalen Position des 
horizontalen Scrollbars (-1) deutlich. 

Die Scrollbars sind als visible gekennzeichnet. 

Die voreingestellten Werte (aktuell, minimal und maximal) sind 
auf 0 gesetzt, da diese erst zur Laufzeit berechnet werden können. 
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Die 'CNTL'-Resource für 
den vertikalen Scrollbar. 


Diese 'CNTL'-Resource 
definiert den horizonta- 
len Scrollbar. 


Die Position des 
vertikalen Scrollbars ist 
um einen Punkt zu weit 
nach rechts gesetzt, um 
den rechten Rand des 
Scrollbars mit dem 
Fensterrahmen zu 
vereinigen. 
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Das Feld RefCon ist bei beiden Scrollbars auf den Wert 0 gesetzt, 
da die Scrollbars zur Laufzeit des Programms durch die globa- 
len Variablen gHorizScrollbar bzw. gVertScrollbar unterschie- 
den werden können. 


Die modifizierte Version von Do_MouseDown: 


Do_MouseDown 1: void Do _MouseDown (void) 
reagiert jetzt auf einen 2: 
Klick in den inneren 3: ANor t Darsy 
Bereich des Fensters : MENSONBEE EReEnGOR: 
(Fensterinhalt), indem 6: part = FindWindow (gEvent.where, 
die Funktion &theWindow) ; 
Do_ContentGlick 7: switch (part) 
aufgerufen wird. 8: { 
9% case inSysWindow: 
10: SystemClick (&gEvent, theWindow); 
11: break; 
12: 
134 case inContent: 
14: Do _ContentClick (theWindow); 
15: break; 
16: 
Lin: case inDrag: 
18: Do _DragWindow (theWindow) ; 
19: break; 
20: 
21% case inZoomIn: 
22: case inZoomOut: 
23: Do _ZoomWindow (theWindow, part); 
24: ‚break; 
253 
26: case inGrow: 
27: Do _GrowWindow (theWindow); 
28: break; 
29: 
30: case inGoAway: 
31: Do_CloseWindow (theWindow) ; 
32: break; 
33: 
34: case inMenuBar: 
35: Do MenuCommand ( 
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MenuSelect (gEvent.where)); 
36: break; 
37: } 
38: } 


Wenn FindWindow festgestellt hat, daß der Mausklick im Fen- 
sterinhalt gelegen hat, so gibt diese Funktion den Ergebniswert 
inContent zurück. Do_MouseDown verzweigt dann in Zeile 14 
in die Event-Behandlungsroutine Do_ContentClick und über- 
gibt ihr das Fenster, welches getroffen wurde, als Parameter. 
Do_ContentClick ist für die Reaktion auf einen Mausklick in 
den Fensterinhalt zuständig. 


Die neue Funktion Do_ContentClick: 


1: void Do _ContentClick (WindowPtr theWindow) Do_ContentGlick 
ZH untersucht, ob der 
> SROET Dr Mausklick in einem der 
5 ee beiden Controls liegt. 
6: Point locMouse; Wenn dies der Fall ist, 
7 ControlHandle theControl; dann sorgt diese 
8 Funktion dafür, daß der 
9 locMouse = gEvent .where; Benutzer die Grafik 
10 GlobalToLocal (&1locMouse); scrollen kann. 
11 part = FindControl (locMouse, theWindow, 

&theControl); 
12: 
13# switch (part) 
14: { 
15% case 0: 
16: Do _GraphicsClick (); 
17: break; 
18: 
19: case inThumb: 
20: oldValue = GetCtlValue (theControl); 
21% TrackControl (theControl, locMouse, 

NULL) ; 

22: newValue = GetCtlValue (theControl); 
23: if (oldValue != newValue) 
24: { 
25:5 if (theControl == gVertScrollbar) 
26: Scroll Graphics (theWindow, 


0, oldValue - newValue); 267 
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Bevor die Funktion 
FindConfrol aufgerufen 
wird, müssen die 
Koordinaten des 
Mausklicks auf das 
lokale Koordinaten- 
system des Fensters 
umgerechnet werden. 


2 else 

28: Scroll Graphics (theWindow, 
oldValue - newValue, 0); 

29: Recalc_Scrollbars (theWindow) ; 

30: } 

31: break; 

32: 

33: default: 

34: TrackControl (theControl, locMouse, 

(ProcPtr) &Scroll Proc); 

35: Recalc_ Scrollbars (theWindow); 

36: break; 

37: } 

38: } 


Die Funktion Do_ContentClick wird aufgerufen, wenn der Be- 
nutzer in den Fensterinhalt klickt. Die Aufgabe dieser Funktion 
liegt darin, festzustellen, ob der Mausklick in einem der beiden 
Scrollbars gelegen hat, und dann entsprechend darauf zu reagie- 
ren. 

Do_ContentClick verwendet zu diesem Zweck in Zeile 10 zu- 
nächst die QuickDraw-Funktion GlobalToLocal, um die Koor- 
dinaten des MouseDown-Events auf das lokale Koordinatensystem 
des Fensters umzurechnen. Dies wird nötig, da die Mausklick- 
Koordinaten, die mit dem EventRecord mitgeliefert werden 
(gEvent.where), im globalen Koordinatensystem definiert sind, 
die Funktion FindControl jedoch davon ausgeht, daß die über- 
gebenen Koordinaten auf das lokale Koordinatensystem des 
Fensters bezogen sind. 

In Zeile 11 wird dann die Funktion FindControl aufgerufen, um 
herauszufinden, ob der Mausklick in einem der beiden Scrollbars 
gelegen hat. Das Fenster, in welchem FindControl suchen soll, wird 
mit dem Parameter theWindow spezifiziert. Dieser Parameter ist 
die Adresse des Fensters, in dem der Mausklick liegt. FindControl 
gibt durch den Ergebniswert an, ob ein Control getroffen wurde, 
und wenn dies der Fall ist, in welchen Teil des Controls geklickt 
wurde. Wenn ein Control getroffen wurde, so gibt FindControl 
den ControlHandle dieses Controls in der Variablen theControl 
zurück. 
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In Zeile 13 wird anhand des Ergebniswertes von FindControl 


entschieden, wie auf den Mausklick reagiert wird. Liegt der 

Mausklick nicht in einem Scrollbar (FindControl hat den Wert0 Do_GraphicsClick ist 
zurückgegeben), so wird in Zeile 16 die neu definierte Funktion eine Dummy-Funktion, 
Do_GraphicsClick aufgerufen. Do_GraphicsClick ist (zur Zeit) die erst bei späteren 
eine Dummy-Funktion ohne Inhalt und kann in späteren Projek- Erweiterungen verwen- 
ten mit Funktionalität versehen werden, um auf einen Klick in det wird. 

die Grafik zu reagieren. 

Liegt der Klick im Thumb eines Scrollbars, so wird in Zeile 20 

zunächst der aktuelle Wert des Controls zwischengespeichert, 

indem die Funktion GetCtlValue aufgerufen wird. Dieser Wert 

wird zwischengespeichert, um nach dem Verschieben des Thumbs 

die Differenz zwischen der alten und der neuen Position auszu- 

rechnen und entsprechend zu scrollen. 

In Zeile 21 wird die Funktion TrackControl aufgerufen, um dem 

Benutzer die Möglichkeit zu geben, den Thumb zu verschieben. 

TrackControl übernimmt die Kontrolle und verfolgt die Maus- 

position solange, bis der Benutzer die Maustaste losläßt. 

Der neue Wert des Scrollbars wird in Zeile 22 durch den erneu- 

ten Aufruf von GetCtlValue abgefragt und in der lokalen Vari- 

ablen newValue abgelegt. Wenn der neue Wert ungleich dem 

alten Wert ist, so hat der Benutzer den Thumb verschoben, und 

das Programm reagiert in den Zeilen 25 bis 30, indem die Grafik 

gescrollt wird. 

In welcher Richtung gescrollt werden soll (horizontal oder verti- 

kal), hängt davon ab, welcher der beiden Scrollbars getroffen 

wurde. Die lokale Variable theControl verweist auf den Scrollbar, 

auf welchen der Benutzer geklickt hat. Diese Variable wird mit 

der globalen Variablen gVertScrollbar verglichen, um festzu- 

stellen, ob der vertikale Scrollbar getroffen wurde. Ist dies der 

Fall, so wird die Scroll-Routine Scroll_Graphics in Zeile 26 so Scroll_Graphics ist für 
aufgerufen, daß ihr die Anzahl der zu scrollenden Punkte an- das Verschieben der 
stelle des letzten Parameters (vertikal) übergeben wird. Ist der Grafik verantwortlich. 
vertikale Scrollbar nicht getroffen, so bleibt eigentlich nur der 

horizontale übrig, und Scroll_Graphics wird in Zeile 28 so auf- 

gerufen, daß horizontal gescrollt wird. 

Nachdem gescrollt wurde, muß das Verhältnis zwischen den 

verdeckten Teilen der Grafik und dem Fenster neu überprüft 

werden. Dies geschieht, indem in Zeile 29 die neue Funktion 
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Scroll_Proc isteine Call- 
Back-Routine, die dafür 
sorgt, daß die Grafik 
gescrollt wird, solange 
der Benutzer die 
Maustaste gedrückt hält. 
Sie wird eingesetzt, 
wenn der Benutzer z.B. 
in den 'Pfeil nach oben" 
des Scrollbars geklickt 
hat. 


Recalc_Scrollbars aufgerufen wird. Recalc_Scrollbars vergleicht 
den verdeckten Teil der Grafik mit dem Fenster und modifiziert 
die Scrollbars entsprechend. 

Hat der Benutzer in einen anderen Teil als den Thumb des Scrollbars 
geklickt, so wird in Zeile 34 die Funktion TrackControl aufge- 
rufen. Im Gegensatz zum Aufruf von TrackControl bei einem Klick 
in den Thumb wird hier die Adresse einer "Call-Back-Routine" 
übergeben. Diese Routine (Scroll_Proc) wird von TrackControl 
wiederholt aufgerufen, solange der Benutzer die Maustaste ge- 
drückt hält. Scroll_Proc sorgt dann dafür, daß die Grafik gescrollt 
und der Thumb des Scrollbars neu positioniert wird. 

Nachdem gescrollt wurde, muß das Verhältnis zwischen dem 
verdeckten Teil der Grafik und dem Fenster neu überprüft wer- 
den. Daher wird in Zeile 35 die Funktion Recalc_Scrollbars 
aufgerufen, um diese Aufgabe zu erledigen. 


Die neue Funktion Scroll_Proc: 


1: pascal void Scroll Proc ( 


ControlHandle theControl, 
short part) 
2: { 
3: short amount = 0; 
4: WindowPtr theWindow; 
Sis 
6: thewindow = (**theControl) .contrlOwner; 
7% 
8: switch (part) 
9: { 
10: case inPageÜp: 
13: amount = 
- (theWindow->portRect..bottom-36) ; 
12: break; 
13: 
14: case inPageDown: 
15: amount = 
theWindow->portRect .bottom-36; 
16: break; 
177: 
18: case inUpButton: 
19: amount = -20; 
20: break; 
21: 


22: case inDownButton: 

23: amount = 20; 

24: break; 

25: } 

26: 

27: if (theControl == gVertScrollbar) 
28: Do _Scroll (theWindow, 0, amount); 
29: else. 

30: Do_Scroll (theWindow, amount, 0); 
3a} 


Die Funktion Scroll_Proc wird von TrackControl wiederholt 
aufgerufen, solange die Maustaste gedrückt ist und sich die 
Mausposition innerhalb des getroffenen Scrollbar-Teils befindet. 
TrackControl übergibt dieser "Call-Back-Routine" den Control- 
Handle auf den getroffenen Control (theControl) sowie den 
Identifikationscode für den getroffenen Scrollbar-Teil (part). 
Scroll_Proc sorgt dafür, daß der Scrollbar-Thumb neu positio- 
niert wird, und daß die Grafik gescrollt wird. 

Die Funktion Scroll_Proc holt sich zunächst die Adresse des 
Fensters aus dem ControlRecord des getroffenen Controls. Dies 
geschieht in Zeile 6, indem der ControlHandle dereferenziert wird, 
um an den ControlRecord zu gelangen und dort auf das Feld 
contrlOwner zuzugreifen. Dieses Feld enthält den WindowPtr 
auf das Fenster, zu dem der Control gehört. Die Funktion 
Scroll_Proc braucht durch diesen "Klimmzug" nicht auf die glo- 
bale Variable gWindow zuzugreifen, was eine Erweiterung des 
Programms in bezug auf die Verwaltung mehrerer Fenster er- 
leichtert. 

In Zeile 8 wird anhand des von TrackControl übergebenen 
Identifikationscodes entschieden, in welche Richtung und um 
wieviele Punkte gescrollt werden soll. 

Hat der Benutzer in den "Seiten-Blättern"-Bereich des Scrollbars 
(inPageUp oder inPageDown) geklickt, so soll jeweils um eine 
Seite (Zeichenbereichshöhe oder Zeichenbereichsbreite) gescrollt 
werden. Die Höhe des Zeichenbereiches entspricht dem 
portRect.bottom des Fensters minus 16 Punkte für den Scroll- 
bar. Die "Human Interface Guidelines" schreiben vor, daß bei 
diesem sogenannten "Paging" jeweils 20 Punkte der letzten Seite 
sichtbar bleiben sollen. Die Scroll-Distanz ergibt sich daher aus 
portRect.bottom minus 36 (16 + 20) Punkte. 
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Do_Scroil sorgt für das 
Verschieben der Grafik 
bzw. für eine neue 
Positionierung des 
Scrollbar-Thumbs. 


Je nach dem, ob der Benutzer nach oben bzw. links oder nach 
unten bzw. rechts scrollen will, wird noch das Vorzeichen ge- 
setzt, so daß der Wert amountH bzw. amountV auch die Rich- 
tung, in die gescrollt werden soll, angibt. 

Wenn der Benutzer in den "Pfeil nach oben" (inUpButton) oder 
den "Pfeil nach unten" (inDownButton) geklickt hat, so scrollt 
das Programm jeweils um 20 Punkte in die entsprechende Rich- 
tung. 

In Zeile 28 wird der getroffene Scrollbar mit der globalen Varia- 
blen gVertScrollbar verglichen, um festzustellen, ob der Benutzer 
in den vertikalen oder den horizontalen Scrollbar geklickt hat. Je 
nach dem, ob horizontal oder vertikal gescrollt werden soll, wird 
Do_Scroll in verschiedener Weise aufgerufen. 


Die neue Funktion Do_Scroll: 


l: void Do_Scroll ( 
WindowPtr theWindow, 


short amountH, 
short amountV) 
2: { 
3% amountH = Scroll_Scrollbar ( 
gHorizScrollbar, amountH); 
4: amountV = Scroll_Scrollbar ( 
qgVertScrollbar, amountV); 
93 
6: Scroll Graphics (theWindow, -amountH, 
-amountV); 
2.2.) 


Do_Scroll faßt das Verschieben des Thumbs und das Scrollen 
der Grafik zusammen. 

Der Funktion werden drei Parameter übergeben. Der WindowPtr 
theWindow spezifiziert das Fenster, dessen Inhalt gescrollt wer- 
den soll. Die Parameter amountH bzw. amountV geben die 
Anzahl der Punkte an, um die gescrollt werden soll. Das Vor- 
zeichen dieser Parameter bestimmt die Richtung. 

Zunächst verändert diese Funktion die Position der Scrollbar- 
Thumbs, indem in den Zeilen 3 und 4 die Funktion Scroll_Scrollbar 
aufgerufen wird. Scroll_Scrollbar hat (neben dem Setzen der neuen 
Thumb-Position) die Aufgabe, festzustellen, ob überhaupt noch 


in die gewünschte Richtung gescrollt werden kann, oder ob der 
Scrollbar-Thumb bereits ganz auf dem Minimum oder Maximum 
steht. Wenn der Thumb beispielsweise zu weit links steht, so gibt 
Scroll_Scrollbar die Anzahl an Punkten, um die noch nach links 
gescrollt werden kann, als Ergebniswert zurück. Da die modifi- 
zierten Werte in den folgenden Aufrufen verwendet werden, ist 
sichergestellt, daß nicht zu weit gescrollt wird. 

In Zeile 6 wird schließlich die Funktion Scroll_Graphics aufge- 
rufen, die die Grafik verschiebt. Da die Grafik (verglichen mit 
den Scrollbars) immer in die entgegengesetzte Richtung gescrollt 
wird, werden die Parameter amountH bzw. amountV negiert, 
bevor sie an Scroll_Graphics übergeben werden. 


Die neue Funktion Scroll_Scrollbar: 


1: short Scroll_Scrollbar ( 
ControlHandle 
short 


theControl, 
amount) 
short value, maxValue; 


(theControl); 


(theControl); 


2 

3 

4: 

9% value = GetCt1lValue 
6: maxValue = GetCt1lMax 
7 

8 


if (value + amount > maxValue) 


9: amount = maxValue - value; 
10: 
11: if (value + amount < 0) 
12: amount = -value; 
13; 
14: SetCtlValue (theControl, amount + value); 
15; 
16: return amount; 
17:2} 


Scroll_Scrollbar bekommt den Scrollbar, dessen Thumb verschoben 
werden soll, bzw. die neue relative Position des Scrollbars als 
Parameter. 

In den Zeilen 5 und 6 wird zunächst der aktuelle bzw. der maxi- 
male Wert des Scrollbars abgefragt und in den lokalen Variablen 
value bzw. maxValue abgelegt. 
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Scroll_Scrollbar paßt die 
Position des Scrollbar- 
Thumbs an die neue 
Scroll-Position an. Sie 
übernimmt gleichzeitig 
eine Kontroll- 
funktionalität, indem sie 
den maximalen Wert, 
um den in die ge- 
wünschte Richtung 
gescrollt werden kann, 
beachtet und den 
Rückgabewert entspre- 
chend modifiziert. 
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Die Position des 
Scrollbar-Thumbs bzw. 
der Wert des Controls 
entspricht der Anzahl 
der Punkte, um die die 
Grafik gescrollt ist. Es 
besteht also eine 
eindeutige Beziehung 
zwischen dem 
Scrollbar-Wert und dem 
Koordinatensystem- 
Ursprung. 

Der minimale bzw. 
maximale Wert des 
Scrollbars bildet die 
Grenze für die jeweilige 
Scroll-Richtung. 


Scroll_Graphics ist für 
die eigentliche Aktion 
des Scrollens verant- 

wortlich; sie verschiebt 

die Grafik und sorgt 
dafür, daß die freigeleg- 
ten Bereiche neu 
gezeichnet werden. 


In Zeile 8 wird untersucht, ob der gewünschte aktuelle Wert des 
Scrollbars größer ist als der maximal erlaubte Wert. Ist dies der 
Fall, so verhindert Scroll_Scrollbar, daß zu weit gescrollt wird, 
indem der Ergebniswert amount auf die Differenz zwischen dem 
maximalen und aktuellen Scrollbar-Wert gesetzt wird. Diese 
Differenz entspricht der Anzahl der Punkte, um die noch nach 
rechts bzw. nach unten gescrollt werden kann. 

In Zeile 11 bzw. 12 wird dasselbe Verfahren in umgekehrter 
Richtung angewendet: Hier wird zunächst abgefragt, ob der neue 
gewünschte Wert (value + amount) im negativen Bereich liegt. 
In diesem Fall würde zu weit nach links bzw. oben gescrollt. Um 
dies zu verhindern, wird in Zeile 12 der Ergebniswert amount auf 
den negierten aktuellen Thumb-Wert (-value) gesetzt. Dieser Wert 
entspricht der Anzahl der Punkte, um die noch nach links bzw. 
nach oben gescrollt werden kann. 

In Zeile 14 wird der Scrollbar auf den neuen Wert gesetzt, was 
dazu führt, daß die Position des Scrollbar-Thumbs verschoben 
wird. 

Der (auf die Grenzwerte des Scrollbars beschränkte) Scroll-Wert 
amount wird in Zeile 16 zurückgegeben. Dieser Wert wird von 
der aufrufenden Funktion Do_Scroll dazu verwendet, die Funktion 
Scroll_Graphics aufzurufen. 


Die neue Funktion Scroll_Graphics: | 


1: void Scroll_ Graphics (short 
short 


amountH, 
amountV) 
Sa! 

Rect 
RgnHandle 


rect2Scroll; 
updateRgn; 


Set _DrawingEnv (theWindow) ; 

rect2Scroll = theWindow->portRect; 

rect2Scroll.bottom -= 15; 

rect2Scroll.right -= 15; 

updateRgn = NewRgn (); 

ScrollRect (&rect2Scroll, amountH, 
amountV, updateRgn); 

SetClip (updateRgn); 


HH 
HOVcVonQıauw wm 
Eon ee) Sehne ide, wende eh 
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13: Draw Graphics (theWindow); 


14: Set_WindowEnv (theWindow); 
15: DisposeRgn (updateRgn); 
16: } 


Die Funktion Scroll_Graphics übernimmt das Scrollen des Fen- ° 

sterinhaltes (der Grafik). Das Fenster bzw. die Anzahl der Punkte, 

um die horizontal bzw. vertikal gescrollt werden soll, werden 

ihr als Parameter übergeben. 

Scroll_Graphics sorgt zunächst dafür, daß der Koordinaten- Die Scrollbars nehmen 
systemursprung so gesetzt wird, daß er der verschobenen Gra- beider Berechnung nur 
fik entspricht, indem in Zeile 6 die Funktion Set_DrawingEnv 15 Punkte ein, da sie um 
aufgerufen wird. Set_DrawingEnv verwendet die QuickDraw- einen Punkt zu weit 
Funktion SetOrigin, um den Koordinatensystemursprung so zu nach rechts bzw. nach 
setzen, daß er mit der verschobenen Grafik synchronisiert ist. unten positioniert sind, 
Das Rechteck, welches gescrollt werden soll, entspricht dem um mit dem Fenster- 
Zeichenbereich, der sich aus dem portRect des Fensters (innerer rahmen zu 

Bereich des Fensters) minus 15 Punkte in horizontaler bzw. ver- verschmelzen. 
tikaler Richtung (Platz für die Scrollbars) ergibt. 

Dieses Rechteck wird in Zeile 11 an die QuickDraw-Funktion 

ScrollRect übergeben, welche den Inhalt des Rechtecks verschiebt. 

Die Scroll-Richtung und die Anzahl der Punkte, um die gescrollt 

werden soll, wird durch die Parameter amountH bzw. amountV 

angegeben. ScrollRect berechnet auch den Bereich, der durch das 

Verschieben der Grafik freigelegt wurde, und legt diesen Bereich 

in der übergebenen Region updateRgn ab. ScrollRect setzt vor- 

aus, daß die übergebene Region bereits angelegt worden ist, da- 

her wird dies in Zeile 10 mit Hilfe der QuickDraw-Funktion 

NewRgn getan. Zeile 12 sorgt durch den Aufruf von SetClip dafür, 

daß Draw_Graphics in Zeile 13 nur in dem Bereich zeichnet, der 

auch wirklich neu gezeichnet werden darf, indem die Clipping- 

Region auf den neuzuzeichnenden Bereich gesetzt wird. Dieses 

Clipping bewirkt einen ruhigen und schnellen Bildschirmauf- 

bau, da die Teile der Grafik, die noch intakt sind, nicht übermalt 

werden. 

Der Aufruf von Set_WindowEnv in Zeile 14 sorgt dafür, daß die 

Clipping-Region wieder dem gesamten Fensterinhalt entspricht, 

und daß der Ursprung des Koordinatensystems auf den norma- 

len Ursprung (0,0) zurückgesetzt wird. 
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Da Scroll_Graphics keinen Speicher verschwenden soll, wird in 
Zeile 15 die Region updateRgn mit einem Aufruf von DisposeRgn 
freigegeben. 


Die modifizierte Version von Set_DrawingEnv : 


1: void Set_DrawingEnv (WindowPtr theWindow) 
2: { 

3 Rect drawableRect; 

4: Point origin; 

5: 

6 SetPort (theWindow) ; 

7 

8: origin.h = GetCtlValue (gHorizScrollbar); 
9: origin.v = GetCtlValue (gVertScrollbar); 
10: SetOrigin (origin.h, origin.v); 

11: 

12: drawableRect = theWindow->portRect; 

13: drawableRect.right -= 15; 
14: drawableRect.bottom -= 15; 

15: ClipRect (&drawableRect); 

16: } 


Abb. 12-14 Die veränderte Version von Set_DrawingEnv setzt den Ursprung 
Set_Drawingenv des Koordinatensystems neu, so daß er mit der verschobenen 
synchronisiert den Grafik synchronisiert ist. 

Koordinatensystem- Wenn die Grafik verschoben ist, so entsprechen die Werte der 
ursprung mitder Scrollbars der Anzahl der Punkte, um die die Grafik verschoben 
Position der Scrollbar-- ist. Der Koordinatensystemursprung kann daher an den aktuel- 
Thumbs, d.h. mitder len Werten der Scrollbars abgelesen werden. Dies geschieht in 
Anzahl der Punkte, um den Zeilen 8 und 9, indem die Funktion GetCtlValue aufgerufen 

die gescrollt wurde. wird, um den aktuellen Wert der Scrollbars abzufragen. 
Der Aufruf von SetOrigin in Zeile 10 setzt den Koordi- 
natensystemursprung so, daß die linke obere Ecke des 
Fensters die übergebenen Koordinaten hat. Die linke obe- 
re Ecke des Fensters hat nach diesem Aufruf beispielswei- 
se die Koordinate (0, 40), wenn zweimal vertikal gescrollt 
wurde. Sämtliche QuickDraw-Funktionen beziehen sich 
N P. 00 ‚oo aufdiesen Koordinatensystemursprung und zeichnen daher 

x ie nach dem Aufruf von SetOrigin an einer anderen Stelle. 
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Die veränderte Version von Set_WindowEnv: 


1: void Set_WindowEnv (WindowPtr theWindow) Set_WindowEnv setzt 
2: { den Koordinatensystem- 
3: SetPort (theWindow) ; ursprung wieder auf die 
es. Wera (0208 ursprüngliche Position 
5% ClipRect (&theWindow->portRect); & ” 

e (0,0) zurück. 


Set_WindowEnv sorgt in Zeile 4 dafür, daß der Koordinaten- 
systemursprung (das Koordinatenpaar der linken oberen Ecke 
des Fensters) wieder auf (0,0) steht, indem SetOrigin mit (0,0) 
aufgerufen wird. Sämtliche QuickDraw-Funktionen zeichnen jetzt 
ausgehend von diesem (normalen) Ursprung des Koordinaten- 
systems. 

Dieses "Zurücksetzen" des Koordinatensystems wird notwendig, 
da auch die Scrollbars im lokalen Koordinatensystem des Fen- 
sters definiert sind (sie werden ja auch mit QuickDraw-Funktio- 
nen gezeichnet). Würde der Ursprung des Koordinatensystems 
nicht zurückgesetzt, so würden sich auch die Scrollbars verschieben 
(ein witziges User-Interface !). 


Die neue Funktion Adjust_Scrollbars: 


: void Adjust_Scrollbars (WindowPtr theWindow) Wenn das Fenster 
dt vergrößert oder 
short newPos, newSize; verkleinert wurde, sorgt 


1 

2 

3 

4: ; = 
34 newPos = theWindow->portRect.right-15; Adjust_Serolibars dafür, 
6 

7 

8 


newSize = theWindow->portRect .bottom-13; daß die Position und 
Größe der Scrollbars an 
R HideControl (gVertScrollbar); die neue Fenstergröße 
9: MoveControl (gVertScrollbar,newPos,- 1); angepaßt wird. 
10: SizeControl (gVertScrollbar,16,newSize); 
11: 
12: newPos = theWindow->portRect.bottom - 15; 
13% newSize = theWindow->portRect.right - 13; 
14: 
15: HideControl (gHorizScrollbar); 
16: MoveControl (gHorizScrollbar,-1,newPos); 
1: SizeControl (gHorizScrollbar,newSize,16); 
18: 
19; Recalc_Scrollbars (theWindow); 
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20: 

21: ShowControl (gHorizScrollbar); 
22: ShowControl (gVertScrollbar); 
23: } 


Adjust_Scrollbars wird von Do_GrowWindow und auch von 
Do_ZoomWindow aufgerufen, um die Position und Größe der 
Scrollbars an eine veränderte Fenstergröße anzupassen. 
Zunächst wird in den Zeilen 5 bis 10 dafür gesorgt, daß der ver- 
tikale Scrollbar an eine neue Fenstergröße angepaßt wird. Dafür 
sind zwei Parameter interessant: 

1. Die neue horizontale Position des Scrollbars, die sich in Zeile 5 
aus der Fensterbreite (portRect.right) minus 15 Punkte (Scrollbar- 
Breite minus 1) ergibt. 

2. Die neue Größe (Höhe) des Scrollbars, die sich in Zeile 6 aus 
der Höhe des Fensters (portRect.bottom) minus 13 Punkte 
(Scrollbar-Breite minus 3) ergibt. 

Die etwas merkwürdig wirkenden Konstanten, die bei der Posi- 
tion bzw. der Höhe des Scrollbars abgezogen werden, ergeben 
sich daher, daß die Ränder eines Scrollbars, der am Fensterrand 
liegt, verdeckt werden sollen. Daher wird die Position des Scrollbars 
(der eigentlich 16 Punkte breit ist) einen Punkt zu weit nach rechts 
geschoben. Die Länge des Scrollbars entspricht der Höhe des 
Fensters minus 13 Punkte, da der vertikale Scrollbar unten Platz 
für die Grow-Box lassen muß. 

Bevor die Position und Größe des Scrollbars verändert werden, 
wird der Scrollbar in Zeile 8 zunächst versteckt, indem HideControl 
aufgerufen wird. Dieses "Verstecken" des Scrollbars bewirkt, daß 
er bei der nachfolgenden Veränderung der Position bzw. der Höhe 
nicht hin- und herspringt und erzeugt damit einen harmonischeren 
Bildschirmaufbau. 

In Zeile 9 wird der vertikale Scrollbar mit einem Aufruf von 
MoveControl an seine neue Position (linke obere Ecke des Controls) 
gebracht. Diese Position ergibt sich aus der berechneten neuen 
horizontalen Position (newPos) und der vertikalen Position (-1). 
Auch hier wird ein Rand des Scrollbars (der obere) durch eine 
entsprechende Positionierung (-1) verdeckt. 

Der Aufruf von SizeControl in Zeile 10 sorgt dafür, daß der ver- 
tikale Scrollbar an die neue Fensterhöhe angepaßt wird. Diese 
Funktion ändert die Größe des Scrollbars auf dieübergebene Breite 





bzw. Höhe. Als neue Höhe wird die berechnete Höhe (newSize), 
als neue Breite die übliche Scrollbar-Breite (16 Punkte) überge- 
ben. 

Das beschriebene Verfahren wird in den Zeilen 12 bis 17 für den 
horizontalen Scrollbar wiederholt, um dessen neue Position und 
Größe zu bestimmen. 

Die Zeilen 12 bis 17 bewirken die Positionierung bzw. Berech- 
nung der neuen Breite des horizontalen Scrollbars. 

In Zeile 19 wird die Funktion Recalc_Scrollbars aufgerufen, um 
die maximalen Werte der Scrollbars neu zu berechnen. Dies wird 
nötig, da durch eine Vergrößerung bzw. Verkleinerung des Fen- 
sters der verdeckte Bereich der Grafik verändert werden kann. 
Da die maximalen Werte der Scrollbars mit der Anzahl der ver- 
deckten Punkte der Grafik übereinstimmen sollen (sie bilden die 
Grenzwerte beim Scrollen), ist diese Neuberechnung sehr wichtig. 
In den Zeilen 21 bzw. 22 werden die beiden Scrollbars schließ- 
lich wieder sichtbar gemacht, indem die Funktion ShowControl 
aufgerufen wird. 


Die neue Funktion Recalc_Scrollbars: 


1: void Recalc_Scrollbars (WindowPtr theWindow) 
2:4 
3: short drawRectH, drawRectV, 
4: contSizeH, contSizeV, 
58 invisPoints; 
6: 
7 drawRectH= theWindow->portRect.right-15; 
8 drawRectV= thewWindow->portRect .bottom-15; 
9 Get _ContentSize (theWindow, &contSizeH, 
&contSizeV); 
10: invisPoints= GetCtlValue (gVertScrollbar); 
11: if (contSizeV - invisPoints > drawRectV) 
22: invisPoints += contSizeV - invisPoints 
- drawRectV; 
193% 
14: if (invisPoints > 0) 
15: { 
16: HiliteControl (gVertScrollbar, 0); 
17: SetCtlMax (gVertScrollbar,invisPoints); 
18: } 
19: else 


12.3 MINIMUM4 





Recalc_Scrollbars 
berechnet die maxima- 
len Werte der Scrollbars 
anhand der Fenster- 
größe bzw. anhand der 
aktuellen Scroll- 
Position. Diese Funktion 
sorgt auch dafür, daß 
die Scrollbars (nach 
einer Größenänderung 
des Fensters) aktiviert 
werden, wenn Teile der 
Grafik verdeckt sind. 
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Wenn die gesamte 
Grafik sichtbar ist, 
werden die Scrollbars 
deaktiviert. 


20: HiliteControl (gVertScrollbar, 255); 

21: 

228 invisPoints=GetCtlValue (gHorizScrollbar); 

23: if (contSizeH - invisPoints > drawRectH) 

24: invisPoints += contSizeH - invisPoints 
- drawRectH; 

25: 

26: if (invisPoints > 0) 

27: { 

28: HiliteControl (gHorizScrollbar, 0); 

29: SetCt1Max (gHorizScrollbar,invisPoints); 

30: } 

31: else 

32: HiliteControl (gHorizScrollbar, 255); 

33: ,} 


Die Funktion Recalc_Scrollbars ist dafür zuständig, die maxima- 
len Werte der Scrollbars mit der Anzahl der verdeckten Punkte 
der Grafik zu synchronisieren. Sie wird aufgerufen, wenn sich 
die Größe des Fensters geändert hat. 

In den Zeilen 7 und 8 wird zunächst die Höhe bzw. die Breite des 
Zeichenbereiches (drawRectV bzw. drawRectH) berechnet. Die 
Höhe des Zeichenbereiches ergibt sich aus der Höhe des Fen- 
sters (portRect.bottom) minus 15 Punkte für den horizontalen 
Scrollbar. Die Breite errechnet sich aus der Breite des Fensters 
minus 15 Punkte für den vertikalen Scrollbar. 

Um das Verhältnis zwischen Zeichenbereich und Grafik berech- 
nen zu können, wird in Zeile 9 die neue Funktion Get_ContentSize 
aufgerufen, die die Höhe bzw. Breite der Grafik zurückgibt. Der 
Aufruf dieser (noch recht primitiven) Funktion sorgt dafür, daß 
Recalc_Scrollbars unabhängig von dem Fensterinhalt ist und somit 
auch für andere Projekte verwendet werden kann, ohne modifi- 
ziert zu werden. Ein Projekt, welches auf diesem Beispielpro- 
gramm aufsetzt, muß lediglich die Funktion Get_ContentSize 
so modifizieren, daß diese die Höhe bzw. Breite der Grafik zu- 
rückgibt. 

In den folgenden Zeilen (10 bis 20) wird der neue maximale Wert 
des vertikalen Scrollbars berechnet und gesetzt. 

Zunächst wird in den Zeilen 10 bis 12 die Anzahl der unsichtba- 
ren Punkte berechnet und in der lokalen Variablen invisPoints 
abgelegt. Die Anzahl der verdeckten Punkte ergibt sich zunächst 
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aus dem aktuellen Wert des vertikalen Scrollbars, der in Zeile 10 


mit einem Aufruf von GetCtlValue abgefragt wird. 
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Der aktuelle Wert des vertikalen Scrollbars (Position des Thumbs) 
entspricht der Anzahl der Punkte, um die die Grafik nach oben 
gescrollt ist. Dieser Wert entspricht also der Anzahl der Punkte, 
die durch Scrollen unsichtbar geworden sind. 

Die wirkliche Anzahl der verdeckten Punkte (und damit der 
maximale Wert des Scrollbars) ergibt sich weiterhin aus der An- 
zahl der Punkte, die verdeckt werden, weil das Fenster nicht hoch 
genug ist. Ist das Fenster kleiner als die Grafik, so wird die An- 
zahl der verdeckten Punkte (invisPoints) um die Differenz zwi- 
schen Grafikhöhe (contSizeV) und der Zeichenbereichhöhe 
(drawRectV) erhöht. Bei dieser Berechnung muß auch die Ver- 
schiebung der Grafik mit einbezogen werden, die sich in der lo- 
kalen Variablen invisPoints befindet (Anzahl der Punkte, die durch 
Scrollen unsichtbar geworden sind). 

Wenn Teile der Grafik unsichtbar sind (invisPoints > 0), so muß 
der Scrollbar aktiviert werden und das Maximum des Scrollbars 
auf die Anzahl der unsichtbaren Punkte gesetzt werden. Dies 
geschieht in Zeile 16, indem die Funktion HiliteControl aufge- 
rufen wird und durch den Parameter 0 (active) spezifiziert wird, 
daß der Scrollbar aktiviert werden soll. 

Zeile 17 setzt den maximalen Wert des Scrollbars durch einen 
Aufruf der Funktion SetCtlMax auf die Anzahl der unsichtba- 
ren Punkte. Der Scrollbar-Thumb kann jetzt genau um die An- 
zahl der Punkte verschoben werden, die zur Zeit verdeckt sind, 
dadurch ist der Scrollbar mit den verdeckten Teilen der Grafik 
synchronisiert. 

Ist diekomplette Grafik in vertikaler Richtung sichtbar (invisPoints 
ist 0), so wird der Scrollbar in Zeile 20 disabled (Aufruf von 


Abb. 12-15 

Das Verhältnis zwischen 
aktueller Scroll-Position, 
den Scrollbar-Werten 
und der Fenstergröße. 
Da die Grafik um 40 
Punkte nach unten 
gescrollt ist, liegt der 
Koordinatensystem- 
ursprung bei (0,40). 
Dieser Ursprung wird 
durch den aktuellen 
Wert der Scrollbars 
reflektiert. Da das 
Fenster zu klein ist, um 
die gesamte Grafik 
aufzunehmen (in 
vertikaler Richtung), 
entspricht die Differenz 
zwischen dem maxima- 
len- und dem aktuellen 
Wert des vertikalen 
Scrollbars der Anzahl 
der Punkte, um die noch 
nach unten gescrollt 
werden kann. 
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HiliteControl mit dem Wert 255). Diese Reaktion des Programms 
entspricht den "Human Interface Guidelines", die vorschreiben, 
daß die mit einer Grafik verbundenen Scrollbars daktiviert werden 
sollen, wenn die Grafik komplett sichtbar ist. 

Die Zeilen 22 bis 32 wiederholen die Berechnungen für den hori- 
zontalen Scrollbar. 


Die neue Funktion Get_ContentSize: 


Get_ContentSize gibt die 1: void Get _ContentSize ( 
Ausdehnung der Grafik windowPtr theWindow, 
R : 
in den übergebenen short horiz, 
” short *vert) 

Parametern zurück. 2: { 

gi *horiz = 200; 

4: *vert = 200; 

5: } 


Get_ContentSize setzt in dieser (primitiven) Version der Routi- 
ne die Größe der Grafik (horiz und vert) auf die Größe des 
Kreises (200 mal 200 Punkte). Bei einem komplexeren Projekt würde 
hier die Größe der Grafik berechnet. 


Die veränderte Version von Do_Activate: 


Do_Activate versteckt 1: void Do _Activate (void) 
die Scrollbars, wenn das 2: { 
Fenster deaktiviert wird, 5 : WindowPtr theWindow; 
BEE SER: 93 theWindow = (WindowPtr) gEvent .message; 
sichtbar, wenn das 6 DrawGrowIcon (theWindow) ; 
Fenster in den Vorder- 7 
grund geholt wird. 8: if (gEvent.modifiers & activeFlag) 
9: { 
10: ShowControl (gVertScrollbar); 
11: ShowControl (gHorizScrollbar); 
12: } 
13: else 
14: { 
15% HideControl (gVertScrollbar); 
16: HideControl (gHorizScrollbar); 
17: } 
18: } 


>] 
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Die modifizierte Version von Do_Activate unterscheidet jetzt 
zwischen Activate- und DeActivate-Events, indem in Zeile 8 das 
modifiers-Feld des EventRecords untersucht wird. Ist das activate- 
Flag gesetzt (logisches "und" mit der Maske activateFlag = 1), so 
handelt es sich um einen Activate-Event (das Fenster wurde in 
den Vordergrund geholt). In diesem Fall werden die Scrollbars 
in den Zeilen 10 und 11 sichtbar gemacht. 

Handelt es sich bei diesem Activate-Event eigentlich um einen 
DeActivate-Event (logisches "und" des modifiers-Feldes mit der 
Maske activateFlag = 0), so werden die Scrollbars in den Zeilen 
15 und 16 durch den Aufruf von HideControl versteckt. Damit 
folgt das Beispielprogramm den "Human Interface Guidelines", 
die vorschreiben, daß die Scrollbars eines im Hintergrund lie- 
genden Fensters versteckt werden sollen. 


Die modifizierte Version von Do_Update: 


1: void Do_Update (void) 

2: { 

3: windowPtr theWindow; 

4: 

5: theWwindow = (WindowPtr) gEvent .message; 
6 Set_WindowEnv (theWindow); 

7 BeginUpdate (theWindow); 

8: 

9: DrawControls (theWindow) ; 

10: DrawGrowIcon (theWindow) ; 
11: 
12: Set _DrawingEnv (theWindow); 
133 EraseRect (&theWwindow->portRect); 
14: Draw Graphics (theWindow); 
15: Set_WindowEnv (theWindow) ; 
16: 
17: EndUpdate (theWindow); 
18: } 


Die modifizierte Version von Do_Update sorgt in Zeile 9 dafür, 
daß die beiden Scrollbars bei einem Update-Event neu gezeich- 
net werden, indem die Funktion DrawControls aufgerufen wird, 
die sämtliche Controls eines Fensters neu zeichnet. 
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Do_Update sorgt jetzt 
dafür, daß bei einem 
Update-Event auch die 
Scrollbars neu gezeich- 
net werden. 
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Kapitel 13 


Dialoge 


Dieses Kapitel beschreibt die Erzeugung und Verwaltung von 
Dialogen auf dem Macintosh. Es beginnt mit einem Überblick 
über die verschiedenen Dialogtypen, einer Beschreibung der 
Dialogelemente, sowie einer Zusammenfassung der "Human 
Interface Guidelines" in bezug auf die Erstellung von Dialogen. 
Im zweiten und dritten Teil des Kapitels werden die Datenstruk- 
turen und Routinen vorgestellt, die für die Erzeugung und Ver- 
waltung von Dialogen eingesetzt werden. Der vierte Teil de- 
monstriert die Anwendung der Dialog-Manager-Routinen an- 
hand einer erweiterten Version des allseits beliebten Beispiel- 
programms "MINIMUM". 


Ein Dialog ist ein spezielles Fenster, des- 
sen Spezialisierung in der Dateneingabe 
bzw. Datenausgabe liegt. Dialoge werden | "tel: 


Inhaltsverzeichnis erstellen: 


häufig für die Parameterisierung komplexer D Bestehandes Inhaltsperzeichnis ersetzen 
A a DO Buchk apitel aufnehmen 
Befehle eingesetzt. Eine solche Paramete- ld 
risierung ist beispielsweise die Auswahl | | O keine seitenzanı 
hied Opti B it Radi Ö Seitenzahl vor Eintrag Füllzeichen: =] 
verschiedener Optionen (z.B. mit Radio- ® Seitenzahl nach Eintrag 





Buttons), oder die direkte Eingabe von Pa- 
rametern mit Hilfe der Tastatur. Ein wei- 


[Abbrechen ] 














teres Anwendungsgebiet liegt in der In- 
formationsausgabe und in der Entscheidungsabfrage. Dialoge Abb. 13-1 
werden oft für Warnmeldungen oder für Abfragen eingesetzt, Ein Dialog. 
die einfache Entscheidungen verlangen. 


Auf dem Macintosh werden drei Arten von Dialogen verwen- 
det. Diese drei verschiedenen Dialogtypen haben jeweils ein ty- 
pisches Einsatzgebiet, für das sie verwendet werden: 
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1. Modale Dialoge (Modal-Dialogs) 
Ein modaler Dialog wird oft als Reaktion auf 
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einen Menübefehl erzeugt und bietet die 
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Möglichkeit, einen Befehl zu parameterisieren. 
Ein Beispiel für einen solchen "Parameterisie- 
rungs-Dialog" ist der Dialog einer Gra- 
fikapplikation, in welchem die Vergrößerung 
eines Objektes eingegeben werden kann. 

Ein weiteres Anwendungsgebiet für modale 








Dialoge liegt in den sogenannten "Zwangssi- 





tuationen". Solche Situationen liegen vor, wenn 





A Anderungen von “Ohne Titel” sichern? 





Nicht Sichern) [ 





Abb. 13-2 
Zwei modale Dialoge. 


Ein modaler Dialog 
hindert den Benutzer 
daran, andere Fenster 
nach vorne zu holen 
oder einen Menüpunkt 
auszuwählen. 


Nichtmodale Dialoge 
werden (fast) wie ein 
normales Fenster 
behandelt. 


der Benutzer zunächst eine Frage beantworten 
muß, bevor das Programm weiterarbeiten 
kann. Ein Beispiel für eine Zwangssituation 
ist u.a. beim Schließen eines Dokuments 
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gegeben. Möchte der Benutzer ein Dokument 
schließen, dessen Daten verändert worden 





sind, so sollte das Programm einen modalen Dialog erzeugen. In 
diesem Dialog muß der Benutzer entscheiden, ob er das geänderte 
Dokument abspeichern, die Änderungen verwerfen oder die 
Aktion abbrechen möchte. 

Ein modaler Dialog zwingt den Benutzer, diesen Dialog zu be- 
antworten, bevor er andere Aktionen durchführt. Er hindert ihn 
daran, andere Fenster nach vorne zu holen, einen Menüpunkt 
auszuwählen oder in andere Programme zu wechseln. Da ein 
solcher Dialog die Funktionalität des Gesamtsystems einschränkt, 
sollte er nur für kurze Zeit auf dem Bildschirm erscheinen; es 
sollten keine langen "Abfrageketten" erstellt werden, die den Be- 
nutzer in seiner Freiheit beschneiden. 

Generell sollten nichtmodale Befehlsstrukturen (wie z.B. direkte 
Menübefehle) vorgezogen werden, da ein stark modal struktu- 
riertes Programm die Übersichtlichkeit verliert. 


2. Nichtmodale Dialoge (Modeless Dialogs) 

Diese Variante stellt eine Alternative zu den modalen Dialogen 
dar. Ein nichtmodaler Dialog bietet dem Benutzer die Möglich- 
keit, den Dialog (wie ein normales Fenster) in den Hintergrund 
zu schicken. Ein solcher Dialog wird beispielsweise häufig für 
den "Suchen und Ändern"-Dialog eines Textverarbeitungs- 





programms verwendet. Der Benutzer kann (während der Dialog 


sichtbar ist) ein anderes Fenster nach vorne ho- 
len, oder einen Menüpunkt auswählen und 
anschließend wieder in den "Suchen und Än- 
dern"-Dialog zurückkehren. Der Vorteil der 
nichtmodalen Dialoge liegt darin, daß der Be- 
nutzer in seiner "chaotischen” Arbeitsweise 
unterstützt wird. Er kann den laufenden Befehl 
jederzeit unterbrechen, um eine andere Aktion 
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durchzuführen, und den angefangenen Befehl 
anschließend wieder aufnehmen. 


3. Warndialoge (Alerts) 
Alerts sind eine spezielle Art von modalen Dialogen, die ein hohes 
Maß an Integration und einige zusätzliche Möglichkeiten bieten. 
Alerts werden hauptsächlich für die Ausgabe von Fehler- 
meldungen oder die Darstellung einfacher Warn- und Ent- 
scheidungsdialoge verwendet. Ein Alert enthält neben einem 
standardisierten Warn-Icon und statischen Texten meist einen 
einzelnen Button, dessen Betätigung den Alert beendet (Bestä- 
tigungsfunktion). 

Alerts sind sehr einfach zu programmieren, da ihre Erzeugung 
und Verwaltung weitgehend automatisiert ist. Die hohe Integra- 
tion bewirkt jedoch auch gewisse Einschrän- 
kungen in bezug auf die Dialogelemente, die 
in einem Alert verwendet werden können. 
Daher wird diese Art von Dialogen nur für den 
einfachen Informationsaustausch (wie Feh- 
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Abb. 13-3 

Ein typischer An- 
wendungsfall für einen 
nichtmodalen Dialog ist 
der ‘Suchen und 
Ändern’-Dialog eines 
Textverarbeitungs- 
programms. 


Die Datei konnte nicht gesichert werden, 
weil auf dem Volume nicht genügend 
Platz ist. Es fehlen 534 Bytes! 








lermeldungen und Warnungen) verwendet. 


Dialoge sind aus einzelnen Elementen zusammengesetzt, die je- 
weils ein spezielles Aufgabengebiet haben. Die verschiedenen 
Elementarten, die in einem Dialog eingesetzt werden können, 
sind: 


1. Controls 
Controls zählen zu den Bedienungselementen eines Dialogs. Mit 
ihnen werden Optionen für nachfolgende Befehle eingestellt 


Abb. 13-4 

Alerts werden für 
einfache Programm- 
meldungen verwendet. 


Controls sind die 
Bedienungselemente 
eines Dialogs. 
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Statische Texte dienen 
der Informationsaus- 
gabe. 


Texteingabefelder 
dienen der 
Informationseingabe 
(Zahlen- oder Textein- 
gabe). 


Bilder werden für die 
Illustration bestimmter 
Vorgänge verwendet. 


Reicht die Palette der 
Standardelemente nicht 
aus, so kann das 
Programm selbst- 
definierte Dialog- 
elemente verwenden. 





(Radio-Buttons und Check-Boxes) oder Befehle ausgeführt 
(Buttons). 


2. Statische Texte 

Statische Texte sind die Informationselemente eines Dialogs. Sie 
werden zur Informationsausgabe, zur Beschriftung/Erklärung 
oder zur Gruppierung von anderen Dialogelementen verwen- 
det. 


3. Texteingabefelder 

Diese Elemente eines Dialogs werden für die Eingabe von Text 
oder Zahlen verwendet und dienen der Parameterisierung 
nachfolgender Befehle. Ein Texteingabefeld ist eine kleine Text- 
verarbeitung, die wichtige Grundfunktionalitäten (z.B. Selektion 
von Text oder Ausschneiden und Einsetzen) standardisiert. Diese 
Textverarbeitung wird von TextEdit (einem weiteren Manager) 
in Verbindung mit dem Dialog-Manager implementiert. 


4. Bilder 

Bilder werden in vielen Dialogen zur Illustration bzw. als Alter- 
native zu statischen Texten verwendet. Oft erklärt ein kleines 
Bild eine komplexe Funktionalität wesentlich besser als ein 
zeilenlanger Text. 


5. User-Items 

Mit Hilfe von User-Items kann die Palette der Standard-Dialog- 
elemente durch selbstdefinierte Elemente erweitert werden. 
Reichen die beschriebenen Standardelemente eines Dialogs nicht 
aus, um die gewünschte Oberfläche zu gestalten, so können User- 
Items verwendet werden. User-Items werden wie andere Dia- 
logelemente behandelt, ihre Funktionalität (die grafische Dar- 
stellung und die Reaktion auf Mausklicks) wird jedoch vom Pro- 
gramm selbst bereitgestellt. 


Da Dialoge eine zentrale Schnittstelle zwischen Programm und 
Benutzer bilden, ist eine gute Strukturierung von großer Wich- 
tigkeit. Die Dialogstruktur eines Programms ist ein kritischer Punkt 
in bezug auf die Benutzerfreundlichkeit des Gesamtprogramms. 
Ist die Dialogstruktur unübersichtlich, oder entspricht das Design 





nicht den auf dem Macintosh üblichen Standards, so ist das Pro- 
gramm oft als Ganzes schlecht zu bedienen. Eine übersichtliche 
und standardisierte Gestaltung der Dialoge ist daher eines der 
wichtigsten Ziele, die bei der Erstellung der Benutzerschnittstelle 
eines Macintosh-Programms angestrebt werden sollte. 

Eine benutzerfreundliche Dialogstrukturierung kann erreicht 
werden, indem u.a. die folgenden Punkte beachtet werden: 


1. Verwendung der standardisierten Eingabe- bzw. Befehlsele- 
mente des Macintosh (Buttons, Radio-Buttons und Check-Boxes 
etc.). 

Die Verwendung dieser Standardelemente sichert ein einheitli- 
ches Aussehen der Elemente und bildet damit die Grundlage ei- 
ner homogenen Bedienungsoberfläche. 

Beim Einsatz dieser Elemente ist darauf zu achten, daß sie nur in 
ihrem üblichen Kontext eingesetzt werden dürfen. Zweckent- 
fremdungen (z.B. einen Radio-Button wie einen normalen Button 
einzusetzen) sind unbedingt zu vermeiden. 


2. Exakte Einhaltung der gültigen Standards bei der Anordnung, 
Größe und Namensgebung der Dialogelemente. 

Die akribische Einhaltung der gültigen Macintosh-Standards in 
bezug auf das Layout eines Dialogs bzw. seiner Elemente ist extrem 
wichtig für die Akzeptanz eines neuen Programms in der Welt 
des Macintosh. So sollte bei dem Design der Dialoge beispielsweise 
stets darauf geachtet werden, daß die Höhe und Breite der Buttons 
an dem Standard von 20 mal 80 Punkten (umschließendes Rechteck) 
ausgerichtet werden. Sehr kleine oder extrem große Buttons 
verhindern die intuitive Benutzung eines Programms, da ein 
harmonisches Layout unterlaufen wird. 


3. Einheitliches Design. 

Die Dialoge eines Macintosh-Programms sollten nicht nur an den 
gültigen Macintosh-Standards ausgerichtet werden, sondern auch 
innerhalb des Programms konsequent einheitlich gestaltet wer- 
den. So sollte auf konsistenten Sprachgebrauch, sowie auf 
Designaspekte (z.B. die Abstände zwischen Dialogelementen) 
geachtet werden. 
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Dialogelemente sollten 
stets in ihrem üblichen 
Kontext verwendet 
werden. 


Ein ausgereiftes und 
einheitliches Dialog- 
Layout trägt wesentlich 
zum harmonischen 
Erscheinungsbild einer 
Macintosh-Applikation 
bei. 


Konsistenter Sprach- 
gebrauch und exakte 
Positionierung der 
Dialogelemente 
bewirken eine harmoni- 
sche Oberfläche. 
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Der Einsatz von 

Dialogen sollte stets mit 
etwas 'Fingerspitzenge- 
fühl" auf die Benutzer- 
freundlichkeit hin 
überprüft werden. 
Abfrageketten sind in 
Jedem Fall zu vermeiden. 


'DLOG'-Resources 
beschreiben die 
Position, Art und Größe 
des Dialogfensters. 


'DITL'-Resources 
enthalten eine Liste der 
Dialogelemente, die in 
einem Dialog installiert 
werden sollen. 





4. Vermeidung von Abfrageketten. 

Abfrageketten (eine Verkettung modaler Dialoge) wirken auf die 
meisten Benutzer verwirrend, da sie eine Art "Höhlensystem" 
darstellen, in dem man sich leicht verlaufen kann. Auch ver- 
schachtelte Dialoge (ein Dialog, über einem Dialog, über einem 
Dialog...) tragen zur Verwirrung bei, da viele Benutzer spätestens 
nach der zweiten Ebene nicht mehr wissen, wo sie hergekommen 
sind, noch reproduzieren können, wie sie zu diesem Dialog ge- 
kommen sind. 

Anstelle dieser Abfrageketten sollten Dialoge in direkter Reakti- 
on auf eine Benutzeraktion (z.B. eine Menüauswahl) erzeugt 
werden und nach Beantwortung sofort verschwinden. 


13.1 Der Dialog-Manager 


Der Dialog-Manager baut bei der Erzeugung und Verwaltung 
von Dialogen auf dem Window-Manager und dem Control- 
Manager auf. Ein Dialog besteht aus einem Fenster, welches mit 
Hilfe des Window-Managers erzeugt und verwaltet wird. Jeder 
Dialog wird durch eine Dialogbeschreibungs-Resource definiert. 
Diese 'DLOG'-Resources beschreiben die Position und Art des 
Dialogfensters und gleichen in ihrer Struktur einer 'WIND'- 
Resource. Eine '"DLOG'-Resource enthält zusätzlich die Resource- 
ID einer sogenannten "Dialog Item List". Diese 'DITL'-Resource 
enthält eine Liste von Elementbeschreibungen (Buttons, statische 
Texte etc...), die in dem Dialog installiert werden sollen. In die- 
ser Liste ist beispielsweise beschrieben, an welcher Position und 
in welcher Größe ein Button erscheinen soll, sowie welchen Titel 
er bekommt. 

'DLOG!' und 'DITL'-Resources werden in der Regel mit Hilfe des 
Resource-Editors ResEdit erzeugt und anschließend durch den 
Resource-Decompiler DeRez in eine Resource-Description-Datei 
übersetzt. 

ResEdit bietet für die Erstellung und Modifikation der Dialog- 
beschreibungs-Resources einen Dialogeditor, der (vergleichbar 
mit einem Zeichenprogramm) die Gestaltung eines Dialogs 
ermöglicht. Um beispielsweise einen neuen Button zu erzeugen, 
wird das Button-Werkzeug ausgewählt und der Button mit Hil- 


fe der Maus im Dialog positioniert. Soll der Titel des Buttons 
modifiziert werden, so genügt ein Doppelklick, und ResEdit zeigt 
ein Fenster, in dem der Titel eingegeben werden kann. 
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Wenn das Programm einen modalen oder einen nichtmodalen 
Dialog erzeugen will, so übergibt es dem Dialog-Manager die 
Resource-ID einer 'DLOG'-Resource. Der Dialog-Manager lädt 
die DLOG'-Resource bzw. die korrespondierende 'DITL'-Resource 
in den Speicher und erzeugt auf deren Grundlage einen neuen 
Dialog bzw. die Dialogelemente. 


Bei der Abarbeitung des Dialogs wird zwischen modalen und 
nichtmodalen Dialogen unterschieden. 


1. Abarbeitung modaler Dialoge. 

Um die Abarbeitung eines modalen Dialogs zu starten, gibt das 
Programm dem Dialog-Manager direkt nach der Erzeugung des 
Dialogs den Auftrag, auf Mausklicks bzw. Tastatureingaben zu 
reagieren. Der Dialog-Manager übernimmt die Kontrolle und 
wartet darauf, daß der Benutzer die Maustaste drückt oder die 
Tastatur betätigt. Hat der Benutzer ein aktives Dialogelement 
angeklickt, so wird die Kontrolle an das Programm zurückgege- 


13.1 Der Dialog- 


IETETeTSIG 





Abb. 13-5 

Der DITL-Editor von 
ResEdit. 

Dieser Editor erlaubt die 
interaktive Gestaltung 
des Dialogs bzw. der 
Dialogelemente. 


Die Abarbeitung eines 
modalen Dialogs 
entspricht einer Schleife, 
die solange läuft, bis der 
Benutzer das Termi- 
nationskriterium setzt. 
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Die Abarbeitung eines 
nichtmodalen Dialogs 
gliedert sich an die 
Main-Event-Loop an. 


Die Abarbeitung von 
Alerts entspricht im 
Prinzip der eines 
modalen Dialogs. 





ben, welches dann auf die Auswahl des Benutzers (z.B. einen 
Klick in einen Button) reagiert. Ist die Abarbeitung des Dialogs 
durch die Auswahl noch nicht abgeschlossen, so übergibt das 
Programm erneut die Kontrolle an den Dialog-Manager, und der 
Zyklus beginnt von neuem. 


2. Abarbeitung nichtmodaler Dialoge. 

Um die Abarbeitung eines nichtmodalen Dialogs zu implemen- 
tieren, sind Veränderungen an der Main-Event-Loop notwen- 
dig. Die Abarbeitung nichtmodaler Dialoge geschieht parallel zur 
Verwaltung normaler Fenster. Bekommt das Programm einen 
Event, der für einen nichtmodalen Dialog bestimmt ist, so über- 
gibt es diesen Event (z.B. einen Mausklick) an den Dialog-Manager. 
Der Dialog-Manager wertet den Event aus und gibt die Auswahl 
des Benutzers an das Programm zurück, welches mit den ent- 
sprechenden Aktionen reagiert. 


Die dritte Art von Dialogen (die Alerts) basiert auf einem spezi- 
ellen Resource-Type, ihre Erzeugung geschieht über einen eige- 
nen Mechanismus. Die Verwaltung von Alerts entspricht im we- 
sentlichen der eines modalen Dialogs. Alerts bieten jedoch eini- 
ge Vereinfachungen und zusätzliche Optionen, die auf das spe- 
zielle Anwendungsgebiet zugeschnitten sind. Eine nähere Be- 
schreibung der Alerts schließt sich den folgenden Beschreibun- 
gen in bezug auf Dialoge an. 


13.2 Dialoge - Routinen und Datenstrukturen 


Die für die Definition eines Dialogs verwendeten 'DLOG'-Resources 
entsprechen im Prinzip der Definition eines Fensters ('WIND'- 
Resource). Der einzige Unterschied besteht darin, daß ein zu- 
sätzliches Feld existiert, welches auf die zu diesem Dialog gehö- 
rende Dialog-Item-List (DITL'-Resource) verweist. 


l: resource 'DLOG' (128) { 
2: {100, 100, 270, 485}, 
3: dBoxProc, 
4 visible, 
5 noGoAway, 


vosono 


Die 'DLOG'-Resource entspricht in den ersten Zeilen (1-6) der 
Definition einer 'WIND'-Resource. Sie beginnt mit der Spezifika- 
tion des umschließenden Rechtecks in Zeile 2. 

Zeile 3 gibt den Fenstertyp dieses Dialogfensters (dBoxProc) an. 
Da diese Art von Fenstern keinen Platz für ein Schließfeld hat, 
wird in Zeile 5 die Konstante noGoAway verwendet. 

Das RefCon wird in dieser Dialogbeschreibungs-Resource auf 
den Wert 0 gesetzt. 

Das zusätzliche Feld (Zeile 7) gibt die Resource-ID der korres- 
pondierenden 'DITL'-Resource (128) an. 

Da ein Fenster vom Typ dBoxProc keine Titelleiste besitzt, bleibt 
der Titel-String in Zeile 8 leer. 


Die zu einer 'DLOG'-Resource gehörende 'DITL'-Resource 
enthält eine Liste von Elementbeschreibungen, die die 
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einzelnen Dialogelemente definieren. Jede dieser Ele- 


[er 





mentbeschreibungen enthälteinen Identifikationscode (Art 





des Elements), ein umschließendes Rechteck sowie ele- 


Abbrechen 





Cr) 





mentspezifische Felder. 


1: resource 'DITL' (130) { 

2 { /* array DITLarray: 5 elements */ 
3: /* [1] */ 

4: {99, 152, 119, 232}, 
34 Button { 

6 enabled, 

2) HOR'" 

8: Ir 

9: /* 121% 
70% {99, 18, 119, 98}, 
11% Button { 
12: enabled, 
13: "Abbrechen" 
14: }, 
15: 1.633. 8%. 
16: {93, 146, 123, 236}, 


Abb. 13-6 

Die nebenstehende 
'DITL'-Resource 
definiert die Dialog- 
elemente des in der 
Abbildung gezeigten 
Dialogs. 
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Jedes Dialogelement 
besitzt ein um- 
schließendes Rechteck, 
sowie einen Identifika- 
tionscode für die Art des 
Elements. Die nachfol- 
genden Felder enthalten 
elementspezifische 
Informationen. 


17: Picture { 

18: disabled, 

19: 129 

2.0: }r 

21: /* [4] */ 

22% {59, 22, 75, 229}, 
233 EditText { 

24: enabled, 

25: 

26: }r 

27: FR 5] 87 

28: {14, 18, 47, 251}, 
29: StaticText { 

30: disabled, 

31: "Geben Sie das Paßwort für den 
Zugriff auf *0 ein:" 

33} } 

34: } 

35: }; 


Diese 'DITL'-Resource enthält die folgenden 5 Dialogelemente: 


1. Einen OK-Button (Zeilen 4-8) 

Zunächst wird in Zeile 4 (wie bei jedem Dialogelement) das 
umschließende Rechteck des Elements definiert. Dieses Recht- 
eck definiert die Position und Größe des Buttons im lokalen Ko- 
ordinatensystem des Fensters. 

In Zeile 5 wird der Identifikationscode für einen Button durch 
die vordefinierte Konstante "Button" eingetragen. Durch diesen 
Identifikationscode erkennt der Dialog-Manager, welche Art von 
Dialogelement er erzeugen soll, bzw. wie die folgenden (Button- 
spezifischen) Felder zu interpretieren sind. 

In Zeile 6 wird das Flag enabled verwendet, um den Button zu 
aktivieren (er kann angeklickt werden). Enthält dieses Feld den 
Wert disabled, so ist der Button inaktiv. 

Zeile 7 definiert den Titel des Buttons ("OK"). 

Dieser Button ist der Default-OK-Button, da er in der 'DITL'- 
Resource an erster Stelle steht. Der Default-OK-Button ist der 
Button, welcher ausgewählt wird, wenn der Benutzer die Return- 
Taste drückt. Die Betätigung des Default-OK-Buttons mit Hilfe 
der Return-Taste dient der schnellen Beantwortung eines Dia- 
logs, dessen Inhalt dem Benutzer bereits bekannt ist. Die Ver- 





wendung der Tastatur zur Bestätigung eines Dialoges wird oft 
von "Macintosh-Profis" verwendet, um die Bedienung eines 
Programms zu beschleunigen. 


2. Einen Abbrechen-Button (Zeilen 10 - 14) 
Die Definition des Buttons erfolgt analog zu der des OK-Buttons. 


3. Ein Bild (Zeilen 16-20) 

Dieses Dialogelement verweist auf ein Bild, welches die dreifache 
Umrandung des Default-OK-Buttons zeichnet. Es ist ein mit 
MacDraw gezeichnetes PICT, welches den üblichen dreifachen 
Rahmen eines Default-OK-Buttons enthält. 

Die Definition des Picture-Dialogelements beginnt in Zeile 16 
mit der üblichen Spezifikation des umschließenden Rechtecks 
des Elements. 

In Zeile 17 folgt die Angabe des Elementtyps (Picture). 

Zeile 18 deaktiviert (disabled) das Bild, so daß es nicht angeklickt 
werden kann. 

In Zeile 19 wird die Resource-ID der (nicht aufgelisteten) PICT- 
Resource angegeben, die das Bild enthält. Eine solche PICT- 
Resource kann mit Hilfe von ResEdit angelegt werden, indem 
das Bild in einem Zeichenprogramm (wie z.B. MacDraw) gemalt, 
ausgeschnitten und anschließend in ResEdit eingesetzt wird. 


4. Ein Texteingabefeld (Zeilen 22-26) 

Die Definition des Texteingabefeldes beginnt in Zeile 22 mit der 
Spezifikation des umschließenden Rechtecks dieses Feldes. 
Zeile 23 enthält den Identifikationscode eines Texteingabefeldes 
(editText). 

In Zeile 24 wird spezifiziert, daß dieses Element aktiv (enabled) 
ist. 

Zeile 25 gibt den voreingestellten Text für dieses Texteingabe- 
feld an. Wenn der Dialog erscheint, so enthält das Texteingabe- 
feld diesen Text. Bei der Eingabe eines Paßwortes ist dieses Ver- 
halten wahrscheinlich unerwünscht, daher ist der String leer. 


5. Einen statischen Text (Zeilen 28-33) 
Die Definition des statischen Textes beginnt mit dem üblichen 
umschließenden Rechteck des Dialogelements in Zeile 28. 


13.2 Dialoge - Routinen 
und Datenstrukturen 


Um die dreifache 
Umrandung des Default- 
Buttons zu erzeugen, 
kann ein Picture 
verwendet werden, 
welches in einer 'PICT'- 
Resource enthalten ist. 
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Statische Texte können 
Platzhalter (*0 bis 3) 
enthalten, an deren 
Stelle zur Laufzeit 
bestimmte Texte (z.B. 
Werte) eingefügt werden 
können. 


Der DialogRecord ist die 
zentrale Datenstruktur 
des Dialog-Managers. 

Ein DialogRecord enthält 

als erstes Feld einen 
WindowRecord; ein 
Dialog-Fenster kann 
daher wie ein normales 
Fenster behandelt 
werden. 





Zeile 29 enthält den Identifikationscode (StaticText). 

Zeile 30 kennzeichnet dieses Dialogelement als disabled (kann nicht 
angeklickt werden). 

Der Inhalt des statischen Textes wird in Zeile 12 durch den Text 
"Geben Sie das Paßwort für den Zugriff auf 0 ein:" definiert. 
Dieser Text enthält einen Platzhalter (X0), an dessen Stelle zur 
Laufzeit andere Texte eingefügt werden können. Auf diese Wei- 
se ist der Dialog universell einsetzbar; er kann (in Verbindung 
mit einer String-Resource) für die verschiedensten Paßwortein- 
gaben verwendet werden, indem die jeweilige String-Resource 
zur Laufzeit des Programms anstelle des Platzhalters eingesetzt 
wird. 


Der Dialog-Manager baut (wie fast alle Manager) auf einer zen- 
tralen Datenstruktur auf. Diese Datenstruktur (der sogenannte 
"DialogRecord") wird vom Dialog-Manager zur Darstellung und 
Verwaltung eines Dialogs verwendet. 


1: struct DialogRecord { 

2 windowRecord window; 

3 Handle items; 

4: TEHandle textH; 

5 short editField; 
6: short editOpen; 

FT short aDefltem; 

8: }; 


Das wichtigste Feld eines DialogRecords ist das erste Feld 
(window). Anstelle dieses Feldes muß man sich einen komplet- 
ten WindowRecord mit all seinen Feldern vorstellen. Da dieses 
Feld an erster Stelle des structs steht, kann ein Pointer auf einen 
DialogRecord verwendet werden, als sei er ein Pointer auf einen 
WindowRecord. Sämtliche Window-Manager-Funktionen (die die 
Adresse eines WindowRecords erwarten), können also auch auf 
einen Dialog angewendet werden. 

Das nächste Feld (items) enthält einen Handle auf die geladene 
'"DITL'-Resource. Der Dialog-Manager verwaltet diese Liste aus- 
schließlich für den internen Gebrauch. Ein Macintosh-Programm 
sollte nie auf dieses Feld bzw. auf die durch diesen Handle ver- 


walteten Daten zugreifen, sondern stattdessen spezielle Zu- 
griffsroutinen verwenden. 

Das Feld textH (Zeile 4) ist ein Handle auf eine Datenstruktur 
vom Typ TERecord, die von allen Texteingabefeldern des Dia- 
logs verwendet wird. Diese Datenstruktur enthält u.a. Informa- 
tionen über die Schriftart und den Schriftstil, in dem die Textein- 
gabefelder gezeichnet werden. Normalerweise arbeitet man nicht 
direkt mit dieser Struktur, sie wird daher nicht näher beschrie- 
ben. 

Die nächsten beiden Felder eines DialogRecords (editField und 
editOpen) sind für die interne Benutzung des Dialog-Managers 
reserviert und sollten nicht verändert werden. 

Das letzte Feld des structs (aDefltem) ist die Nummer des Default- 
OK-Buttons. Normalerweise enthält das Feld aDefltem den Wert 
1 und verweist damit auf das erste Element der Dialogelement- 
liste (üblicherweise ein Button). 


Bevor die Routinen des Dialog-Manager verwendet werden 
können, müssen die Datenstrukturen dieses Managers initiali- 
siert werden. Der Dialog-Manager stellt zu diesem Zweck die 
Funktion InitDialogs zur Verfügung. 


pascal void InitDialogs ( 
ResumeProcPtr resumeProc); 


InitDialogs kann optional die Adresse einer Routine übergeben 
werden, die vom System aufgerufen wird, wenn ein Systemfehler 
auftritt. Diese Routine kann dem Benutzer die Möglichkeit ge- 
ben, geöffnete Dateien abzuspeichern, bevor das Programm au- 
tomatisch beendet wird. Eine solche Funktion sollte einen Dialog 
erzeugen, der den Benutzer über den Systemfehler informiert 
bzw. in welchem er auswählen kann, ob er die Daten sichern will 
oder die Änderungen verwerfen möchte. Wird anstelle des Pa- 
rameters resumeProc der Wert NULL übergeben, so wird das 
Programm automatisch beendet, sobald ein Systemfehler auftritt, 
ohne daß dem Benutzer die Möglichkeit gegeben wird, seine Da- 
ten zu retten. 
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Alle EditText-Felder 
teilen denselben 
TERecord. 
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Um einen Dialog zu erzeugen, stellt der Dialog-Manager die 
Funktion GetNewDialog zur Verfügung. Diese Funktion lädt die 
spezifizierte DLOG'-Resource bzw. die korrespondierende 'DITL'- 
Resource in den Speicher und erzeugt auf der Grundlage dieser 
Dialog-Templates einen neuen Dialog. 


pascal DialogPtr GetNewDialog ( 
short dialogID, 
void *dStorage, 
WindowPtr behind); 


Als ersten Parameter (dialogID) erwartet GetNewDialog die 
Resource-ID der Dialogbeschreibungs-Resource (DLOG'). 
Anstelle des zweiten Parameters (dStorage) kann die Adresse eines 
DialogRecords übergeben werden. Dieser DialogRecord wird dann 
verwendet, um den Dialog zu verwalten. Wenn bei diesem Para- 
meter der Wert NULL übergeben wird, so legt GetNewDialog 
einen nonrelocatable-Block zur Verwaltung des Dialogs an. Wird 
der Dialog nur für kurze Zeit auf dem Bildschirm dargestellt, so 
kann anstelle von dStorage der Wert NULL übergeben werden. 
Soll der Dialog über längere Zeit bestehen bleiben (z.B. bei ei- 
nem nichtmodalen Dialog), so sollte die Adresse einer globalen 
Variablen vom Typ DialogRecord übergeben werden, um eine 
permanente Fragmentierung des Speicherbereichs zu verhindern. 
Der letzte Parameter (behind) kann die Adresse eines bestehen- 
den Fensters enthalten. Der neue Dialog würde dann hinter die- 
sem Fenster erzeugt. In der Regel soll ein Dialog jedoch über 
allen anderen Fenstern dargestellt werden, was erreicht werden 
kann, indem anstelle von behind der Wert -1 übergeben wird. 
Wenn GetNewDialog den Dialog erzeugt und auf dem Bildschirm 
dargestellt hat, gibt diese Funktion die Adresse des DialogRecords 
zurück, mit dem dieser Dialog verwaltet wird. Dieser DialogPtr 
wird von anderen Dialog-Manager-Routinen als Eingabepara- 
meter erwartet, um zu spezifizieren, mit welchem Dialog gear- 
beitet werden soll. 


Nachdem der Dialog mit Hilfe von GetNewDialog auf dem Bild- 
schirm dargestellt wird, muß das Programm für die Abarbeitung 
des Dialogs sorgen. Wenn der Dialog ein modaler Dialog sein 
soll, so ruft das Programm die Funktion ModalDialog auf. 


ModalDialog übernimmt die Kontrolle und wartet auf Be- 
nutzeraktionen. Hat der Benutzer aufeinen aktiven Button, Radio- 
Button oder andere (aktive) Dialogelemente geklickt, so gibt 
ModalDialog die Kontrolle an das Programm zurück und spezi- 
fiziert die Nummer des getroffenen Dialogelements. Ein Macin- 
tosh-Programm reagiert dann, indem es die mit diesem Element 
verbundenen Aktionen durchführt (z.B. Einschalten eines Radio- 
Buttons oder einer Check-Box). 

Hat die Auswahl des Benutzers nicht die Beendigung des Dia- 
logs zur Folge, so ruft das Programm (nachdem die Aktion 
durchgeführt wurde) erneut ModalDialog auf, um auf die näch- 
ste Auswahl des Benutzers zu warten. 

Die Abarbeitung eines modalen Dialogs ist also eine Schleife, in 
der ModalDialog solange aufgerufen wird, bis der Benutzer auf 
einen Button klickt, der den Dialog beenden soll. Ist der Dialog 
beendet, so läßt das Programm den Dialog vom Bildschirm ver- 
schwinden und kehrt in die Main-Event-Loop zurück. 
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pascal void ModalDialog ( 
ModalFilterProcPtr filterProc, 
short *jtemHit); 








Do_Activate 





Wenn ModalDialog aufgerufen wird, so kann anstelle des Para- 
meters filterProc die Adresse einer Event-Filter-Routine über- 
geben werden, die vom Dialog-Manager aufgerufen wird, bevor 
der Event (z.B. ein Mausklick) behandelt wird. Eine solche Fil- 
ter-Funktion werden Sie am Anfang noch nicht benötigen, ihre 
Implementierung wird daher nicht näher beschrieben. Soll die 
Möglichkeit einer Filter-Funktion nicht genutzt werden, so kann 
der Wert NULL übergeben werden. 

Wenn ModalDialog die Kontrolle an das Programm zurückgibt, 
so enthält die Variable, auf die itemHit zeigt, die Nummer des 
getroffenen Dialogelements. Diese Variable wird üblicherweise 
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Die Abarbeitung eines 
modalen Dialogs ist eine 
Schleife, die solange 
läuft, bis der Benutzer 
das Terminations- 
kriterium setzt. 
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verwendet, um zu entscheiden, welche Aktionen durchgeführt 
werden sollen. 


DialogSelect Um einen nichtmodalen Dialog zu verwalten, muß das Programm 
Änderungen in der Main-Event-Loop vornehmen. Da die volle 
Programmfunktionalität während der Abarbeitung eines nicht- 
modalen Dialogs zur Verfügung stehen soll, muß sich das Pro- 
gramm in der Main-Event-Loop befinden, um neben Mausklicks, 
die den Dialog betreffen, auch die normale Event-Verwaltung 

DialogSelect überprüft, zu unterstützen. Um auf Events zu reagieren, die einen nichtmo- 
ob der Event füreinen dalen Dialog betreffen, ruft das Programm (direkt nach Wait- 
nichtmodalen Dialog NextEvent) die Funktion DialogSelect auf. 
bestimmt istund gibt DialogSelect überprüft, ob der vorliegende Event für einen 
die Elementnummer ds nichtmodalen Dialog bestimmt ist. Falls der Event für einen Dia- 
getroffenen Dialog, log bestimmt ist, sorgt DialogSelect für die Abarbeitung des Events, 
elements bzw. de indem sie das getroffene Dialogelement an das Programm zu- 
Adresse des zugehöri- rückgibt, welches dann die entsprechenden Aktionen durchführt. 
gen DialogRecordsan Bezieht sich der Event nicht auf einen Dialog, so behandelt das 
das Programm zurück. Programm diesen Event in der üblichen Art und Weise. 
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Aue 1 Boolean DialogSelect ( 
. £ . pascal Boolean DialogSelec 
m e Abarbeitung a EventRecord *theEvent, 
nichtmodalen Dialogs DialogPtr *theDialog, 
gliedert sich an die short *itemHit); 
Main-Event-Loop an. 


Wenn der Eventeinın Wenn DialogSelect aufgerufen wird, so wird ihr in dem Parame- 
Dialog betrifft, so wirdin ter theEvent die Adresse des EventRecords übergeben, der den 
die entsprechenden von WaitNextEvent zurückgelieferten Event enthält. Ist der Event 
Behandlungsroutinen nicht für einen Dialog bestimmt, so gibt DialogSelect false zu- 
verzweigt. rück. Das Programm fährt dann in derüblichen Abarbeitung des 








13.2 Dialoge - Routinen 
und Datenstrukturen 
Events fort. Wenn der Event für einen Dialog bestimmt ist, so 


gibt DialogSelect den Wert true zurück und spezifiziert in den 
zusätzlichen Ergebniswerten das getroffene Dialogelement und 
den zugehörigen Dialog. 

Die Variable, auf die theDialog zeigt, enthält die Adresse des 
Dialogs, zu dem das getroffene Dialogelement gehört. 

In der Variablen, deren Adresse bei itemHit übergeben wird, gibt 
DialogSelect (wie ModalDialog) die Nummer des getroffenen 
Dialogelements zurück. 

Wenn DialogSelect den Wert true zurück gibt, so verzweigt das 
Programm üblicherweise in eine Behandlungsroutine, die für die 
Abarbeitung sämtlicher nichtmodaler Dialoge verantwortlich ist. 
Diese Behandlungsroutine entscheidet meist anhand des RefCon- 
Feldes des Dialogs, welcher Dialog getroffen wurde, und verzweigt 
in die zu diesem Dialog gehörende Behandlungsroutine. Das 
RefCon-Feld enthält bei nichtmodalen Dialogen üblicherweise 
einen Identifikationscode, durch den die verschiedenen nicht- 
modalen Dialoge unterschieden werden können. 


Ist die Abarbeitung eines Dialogs beendet, so wird die Funktion DisposeDialog 
DisposeDialog aufgerufen. 


pascal void DisposeDialog (DialogPtr theDialog); 


DisposeDialog sorgt dafür, daß der Dialog, der durch den Para- 
meter theDialog spezifiziert wird, vom Bildschirm verschwin- 
det. Ein Aufruf dieser Funktion gibt auch die mit dem Dialog 
verbundenen Datenstrukturen frei. 


Um zur Laufzeit eines Dialogs Manipulationen an den Dialog- 
elementen vorzunehmen oder auf deren Datenstrukturen zuzu- 
greifen, stellt der Dialog-Manager mehrere Funktionen zur Ver- 
fügung. Diese Funktionen ermöglichen den Zugriff auf einzelne 
Dialogelemente. Mit ihnen ist es beispielsweise möglich, den Text 
eines Texteingabefeldes abzufragen oder in Kombination mit 
anderen Routinen eine Check-Box ein- oder auszuschalten. 


Um Manipulationen an einem Dialogelement vorzunehmen, muß GetDitem 


zunächst die Funktion GetDItem aufgerufen werden. Sie sucht 
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GetlText 





ein Element aus der Liste der Dialogelemente heraus und gibt 
einen Handle auf dieses Element bzw. weitergehende Informa- 
tionen an das Programm zurück. Der Handle auf das Element 
kann anschließend als Parameter an Manipulationsroutinen wie 
SetIText, aber auch an Control-Manager-Routinen wie SetCtlValue 
übergeben werden, um Manipulationen an dem Element vorzu- 
nehmen. 


pascal void GetDItem ( 
DialogPtr theDialog, 


short itemNo, 
short *jtemType, 
Handle *item, 
Rect *box) ; 


GetDlItem verlangt als ersten Parameter die Adresse des Dialogs, 
in dem nach einem Element gesucht werden soll. 

Der zweite Parameter (itemNo) spezifiziert die Nummer des 
gesuchten Dialogelements (Reihenfolge wie in der 'DITL'-Re- 
source). 

Die nächsten drei Parameter sind Rückgabeparameter, in denen 
Informationen über das gefundene Element zurückgegeben 
werden. 

In der Variablen, deren Adresse bei itemType übergeben wird, 
legt GetDItem den Identifikationscode des Dialogelements ab. 
Diese Variable enthält nach einem Aufruf von GetDltem bei- 
spielsweise den Identifikationscode für einen Button oder eine 
Check-Box. 

In der Variablen, auf die item zeigt, wird der Handle auf das 
Dialogelement abgelegt. Dieser Handle kann anschließend an 
Manipulationsroutinen übergeben werden. 

Das Rect, auf das box zeigt, enthält nach einem Aufruf von 
GetDItem das umschließende Rechteck des Dialogelements. 


Um auf den Text eines Texteingabefeldes oder eines statischen 
Textes zuzugreifen, steht die Funktion GetIText zur Verfügung. 
Diese Funktion wird in der Regel verwendet, um nach der Abar- 
beitung eines Dialogs auf die Eingaben des Benutzers zuzugrei- 
fen. 
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pascal void GetIText (Handle item, Str255 *text); 


GetIText erwartet als ersten Parameter (item) den Handle auf das 
Dialogelement, auf dessen Text zugegriffen werden soll. Dieser 
Handle entspricht in der Regel dem Ergebniswert der Funktion 
GetDItem. 

Anstelle des Parameters text wird die Adresse eines Pascal-Strings 
übergeben, in welchem GetIText den Inhalt des Textfeldes ab- 
legt. Enthält das Textfeld mehr als 255 Zeichen (ein Eingabefeld 
kann bis zu 32768 Zeichen enthalten), so werden nur die ersten 
255 Zeichen zurückgegeben. 

Soll auf mehr als 255 Zeichen zugegriffen werden, so kann der 
von GetDItem zurückgebene Handle verwendet werden, um mit 
Zugriffsroutinen des TextEdit-Managers auf den kompletten Text 
zuzugreifen. 


Um den Text eines Textfeldes zuändern, steht die Funktion Set[Text Set/Text 
zur Verfügung. Diese Funktion wird oft verwendet, um den In- 
halt eines Texteingabefeldes zur Laufzeit zu setzen. 


pascal void SetIText (Handle item, Str255 *text); 


SetIText erwartet (wie Get[Text) den Handle auf das Dialogelement 
in dem Parameter item. 

Der Text, der in das Textfeld eingesetzt werden soll, wird durch 
den Pascal-String text spezifiziert. 


Um die Platzhalter in statischen Textfeldern (0, *1,*2,*3) durch ParamText 
Strings zu ersetzen, stellt der Dialog-Manager die Funktion 

ParamText zur Verfügung. Diese Funktion wird aufgerufen, bevor 

der Dialog mit Hilfe von GetNewDialog auf den Bildschirm ge- 

bracht wird. Der nächste Aufruf von GetNewDialog führt dazu, 

daß die Texte, die an ParamText übergeben wurden, anstelle der 
entsprechenden Platzhalter eingesetzt werden. 


pascal void ParamText ( Str255 *param0, 
Str255 *paraml, 
Str255 *param2, 
Str255 *param3); 
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Anstelle der String- 
Pointer darf niemals 
NULL übergeben 
werden. 


Eine 'ALRT'-Resource 
enthält Informationen 
über Position und Größe 
des Alerts, sowie 
Informationen über die 
verschiedenen Alert- 
Stages. 


Das Programm kann bei einem Aufruf dieser Funktion bis zu 
vier Pascal-Strings (param0 - param3) übergeben, die anstelle der 
entsprechenden Platzhalter (*0 - 3) in statischen Texten einge- 
setzt werden. Soll ein Parameter nicht verwendet werden, so muß 
ein Leer-String ("\p") übergeben werden. Wichtig ist, daß hier 
nicht der Wert NULL übergeben werden darf (häufige Fehler- 
quelle !). 


13.3 Alerts - Routinen und Datenstrukturen 


Alerts basieren auf einem speziellen Resource-Type (den 'ALRT'- 
Resources), sowie einer korrespondierenden 'DITL'-Resource. Die 
'ALRT'-Resource enthält Informationen über die Position und 
Größe des Alerts, sowie über die verschiedenen Alert-Stufen. Die 
korrespondierende 'DITL'-Resource enthält (wie bei einem Dia- 
log) die Dialogelemente. 


1: resource 'ALRT' (129) { 

2 {40, 40, 143, 379}, 

3 129, 

4: { /*X array: 4 elements */ 
5: /* [1] */ 

6 OK, visible, soundl, 
7 7: [2] 87 

8: OK, visible, soundl, 
9: 7 [3], #7 

10: OK, visible, soundl, 
11: /* [4] */ 

12 OK, invisible, soundl 
13: } 


14: }; 


Diese 'ALRT'-Resource enthält in Zeile 2 zunächst das um- 
schließende Rechteck des Alert-Fensters in globalen Koordina- 
ten. Weitere Informationen über das Fenster (wiebei einer 'DLOG'- 
Resource) existieren nicht, da alle Alerts den gleichen Fenster- 
typ (dBoxProc) verwenden. 

In Zeile 3 wird auf die zu diesem Alert gehörige 'DITL'-Resource 
verwiesen. Diese 'DITL'-Resource enthält (wie bei einem norma- 
len Dialog) die Dialogelemente. 


13.3 Alerts - Routinen 
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Die Zeilen 4 bis 13 enthalten Informationen über die verschiede- 
nen Alert-Stufen (Alert-Stages). Die verschiedenen Stufen eines Die verschiedenen Alert- 
Alerts werden von vielen Programmen verwendet, um bei sStages können verwen- 
mehrmaligem Auftreten desselben Fehlers mit unterschiedlichen det werden, um bei 
Meldungen zu reagieren. Jede Alert-Stufe einer'ALRT'-Resource mehrmaligem Aufruf 
enthält Optionen für die Abarbeitung des Alerts. Wird der Alert desselben Alerts 

das erste Mal erzeugt, so werden die Informationen der unter- unterschiedlich zu 
sten (der vierten) Alert-Stufe verwendet; bei dem zweiten Auf- reagieren. 

ruf die Informationen der dritten und so weiter... 

Der Default-Button eines Alerts wird (im Gegensatz zu norma- 

len Dialogen) automatisch dreifach umrandet und dadurch als 

Default-Button gekennzeichnet. Jede Alert-Stufe enthält die In- 

formation, ob der erste Button der Dialogelementliste (OK-Button) 

oder der zweite (Cancel) als Default-Button gekennzeichnet wird. 

Jede Stufe kann durch diese Option einen unterschiedlichen 

Default-Button haben. Diese Technik wird hauptsächlich dann 

verwendet, wenn der Informations-Text eines Alerts variabel ist 

(ParamText) und die verschiedenen Stufen eines Alerts unter- 

schiedliche Entscheidungsmöglichkeiten bieten. 

Das zweite Feld einer Alert-Stufe gibt an, ob der Alert in dieser 

Stufe sichtbar (visible) oder unsichtbar (invisible) ist. Ist der Dialog 

unsichtbar, so wird nur der übliche Warnton ausgegeben, der 

Alert erscheint aber noch nicht auf dem Bildschirm. Diese Mög- Viele Programme geben 
lichkeit wird von vielen Programmen verwendet, um den Be- beider ersten Fehl- 
nutzer auf Fehlbedienungen hinzuweisen. Wenn der Benutzer bedienung nur einen 
beispielsweise versucht, eine Aktion durchzuführen, dieunmöglich Warnton aus. Bei 

oder unsinnig ist, so geben viele Programme beim ersten Ver- wiederholter Fehl- 
such nur einen Warnton aus. Versucht der Benutzer dann das _bedienung wird dann 
zweite Mal, diese Aktion durchzuführen, so erscheint der Alert, der Alert sichtbar 

in welchem erklärt wird, warum die Aktion nicht durchgeführt gemacht und informiert 
werden kann. Diese "intelligente" Verwaltung der Fehlermel- über den Fehler. 
dungen sorgt für ein angenehmes Verhalten des Programms. Hat 

der Benutzer den Befehl beispielsweise nur versehentlich ausge- 

wählt, so wird er nicht durch den Alert "genervt", sondern durch 

den Warnton auf seinen Fehler hingewiesen. Ein Benutzer, der 

nicht weiß, daß die Aktion unsinnig ist, wird es garantiert ein 

zweites Mal versuchen, was dann zum Erscheinen des Alerts führt. 

Das dritte Feld einer Alert-Stufe spezifiziert, ob und wieviele 

Warntöne (sound0 bis sound3) beim Erscheinen des Alerts aus- 
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Die 'DITL'-Resource 
eines Alerts definiert die 
Elemente, die in dem 
Alert installiert werden 
sollen. Eine solche Alert- 
'DITL'-Resource enthält 
in der Regel nur einen 
statischen Text und ein 
oder zwei Buttons. 





gegeben werden sollen. In der Regel wird nur soundO (kein 
Warnton) oder soundl (ein einzelner Warnton) verwendet. 


Die 'DITL'-Resource eines Alerts entspricht in ihrem Aufbau der 
Definition einer normalen Dialogelementliste. Eine 'DITL'-Re- 
source, die in einem Alert verwendet wird, enthält jedoch in der 
Regel nur einen statischen Text, ein oder zwei Buttons und even- 
tuell ein Icon. Komplexere Elemente (wie z.B. Radio-Buttons oder 
Texteingabefelder) sollten in Alerts nicht verwendet werden. 


1: resource 'DITL' (129) { 

2 t /* [1] */ 

3 {68, 241, 88, 321}, 
4 Button { 

5: enabled, 

6: "OK" 

73 }r 

8 /* [2] */ 

9 {20, 67, 57, 322}, 
10 StaticText { 

11: disabled, 

12: "Dieses Objekt ist geschützt und kann 
daher nicht gelöscht werden!" 
132 } 

14: } 

15:2, }% 


Diese 'DITL'-Resource ist eine typische Alert-'"DITL'-Resource. 
Sie enthält einen Button (Zeilen 3 bis 7) und einen statischen Text 
(Zeilen 9 bis 13). 


Um einen Alert zu erzeugen und für die Abarbeitung zu sorgen, 
stellt der Dialog-Manager vier verschiedene Funktionen zur 
Verfügung, die alle einen Alert auf der Grundlage einer 'ALRT'- 
Resource erzeugen. Diese Funktionen übernehmen die Kontrol- 
le und sorgen für die Abarbeitung des Alerts. Sie umranden den 
Default-Button und erzeugen einen Warnton (je nach Spezifika- 
tion der jeweiligen Alert-Stufe). Hat der Benutzer auf einen der 
Buttons geklickt, so geben diese Funktionen die Elementnummer 
des getroffenen Buttons als Ergebniswert an das Programm zu- 
rück. 


Die Funktion StopAlert erzeugt einen Alert auf der Grundlage 
einer 'ALRT'-Resource und übernimmt gleichzeitig die Kontrol- 
le, um für die Abarbeitung des Alerts zu sorgen. StopAlert zeichnet 
zusätzlich ein standardisiertes Stop-Icon in der linken oberen Ecke 
des Alert-Fensters. Diese Art von Alerts wird ausschließlich für 
Fehlermeldungen oder Meldungen bei Fehlbedienung eingesetzt. 
Ein solcher Alert sollte nur einen statischen Text und einen ein- 
zelnen Button zur Bestätigung der Meldung enthalten, da diese 
Art von Meldungen in der Regel keine Entscheidungsmög- 
lichkeiten zur Verfügung stellt. 





O0 Dieses Objekt ist geschützt und kann 


daher nicht gelöscht werden! 


en 
un 








pascal short StopAlert (short alertID, 
ModalFilterProcPtr filterProc); 


Die Funktion StopAlert erwartet die Resource-ID der 'ALRT'- 
Resource in dem Parameter alertID. 

Der Parameter filterProc kann die Adresse einer Event-Filter- 
Routine spezifizieren, die aufgerufen wird, bevor der Event (z.B. 
ein Mausklick) vom Dialog-Manager behandelt wird. In der Re- 
gel wird diese Möglichkeit nicht verwendet und stattdessen der 
Wert NULL übergeben. 

Der Ergebniswert der Funktion entspricht dem getroffenen Button 
und wird als Entscheidungsgrundlage für nachfolgende Aktio- 
nen verwendet. 


Die Funktion CautionAlert arbeitet wie StopAlert, erzeugt jedoch 
ein standardisiertes Warn-Icon in der linken oberen Ecke des Alert- 
Fensters. 





N ACHTUNG 


Sie sind im Begriff 3 Seiten komplett 


zu löschen! 


— 
Abbrechen 
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StopAlert 


Abb. 13-9 

StopAlert erzeugt ein 
Standard-Stop-Icon in 
der linken oberen Ecke 
des Fensters. 


CautionAlert 


Abb 13-10 
CautionAlert verwendet 
ein standardisiertes 
Warn-Icon. 
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NoteAlert 


Abb. 13-11 

NoteAlert erzeugt ein 
standardisiertes Notiz- 
Icon. 


pascal short CautionAlert (short alertID, 
ModalFilterProcPtr filterProc); 


Diese Funktion wird dann verwendet, wenn der Benutzer im Begriff 
ist, eine gefährliche Aktion durchzuführen (um ihm die Mög- 
lichkeit zum Abbruch der Aktion zu geben). Ein solcher Alert 
enthält in der Regel zwei Buttons, die zur Bestätigung bzw. zum 
Abbrechen der Aktion verwendet werden können. Der defensi- 
ve Button (in der Regel der Abbrechen-Button) muß hierbei der 
Default-Button sein. Eine Situation, in der ein solcher Warn-Alert 
verwendet wird, ist beispielsweise das Löschen einer komplet- 
ten Seite in einem Textverarbeitungsprogramm. Hier wird der 
Benutzer mit einem Warn-Alert nach einer Bestätigung für seine 
Aktion gefragt. 


Die Funktion NoteAlert arbeitet wie StopAlert, erzeugt jedoch 
zusätzlich ein Standard-Notiz-Icon in der linken oberen Ecke des 
Alert-Fensters. 


Die verbundene Grafik-Datei ist 
verändert worden und wird neu 


importiert. 


| 
\E = J 











pascal short NoteAlert (short alertID, 
ModalFilterProcPtr filterProc); 


Diese Art von Alerts wird verwendet, um den Benutzer über 
bestimmte Programmsituationen zu informieren, die nicht in den 
Bereich der Gefahren- oder Fehlermeldungen fallen. Ein Beispiel 
für einen solchen Notiz-Alert ist bei einer Textverarbeitung zu 
finden, wenn der Benutzer darüber informiert werden soll, daß 
eine eingebundene Grafikdatei verändert worden ist und daher 
aktualisiert wird. 


Die letzte der vier Funktionen ist die Funktion "Alert". Sie er- 
zeugt einen variablen Alert, ohne ein standardisiertes Warn- oder 
Informations-Icon in der linken oberen Ecke. Diese Funktion wird 
dann verwendet, wenn der Alert ein eigenes, spezielles Icon er- 


halten soll, welches dann in der 'DITL'-Resource spezifiziert werden 
muß. 





@9 Haben Sie heute schon gefrühstückt? 
_—— 











pascal short Alert (short alertID, 
ModalFilterProcPtr filterProc); 


Die Funktion Alert arbeitet ansonsten wie die bereits beschrie- 
benen Funktionen. 


Um die Alert-Stufe, in der sich der zuletzt erzeugte Alert befin- 
det, zu erfahren, steht die Funktion GetAlrtStage zur Verfügung. 


pascal short GetAlrtStage (void); 


Wenn die verschiedenen Stufen eines Alerts unterschiedliche 
Meldungen enthalten sollen, so kann diese Funktion in Verbin- 
dung mit ParamText dazu verwendet werden, um die der Alert- 
Stufe entsprechenden Texte in Platzhaltern einzusetzen. 


Um die Alert-Stufe des zuletzt erzeugten Alerts auf die erste Stufe 
zurückzusetzen, wird die Funktion ResetAlrtStage verwendet. 


pascal void ResetAlrtStage (void); 


Diese Funktion wird in der Regel verwendet, wenn ein Alert- 
Zyklus durchlaufen ist, um wieder bei der ersten Stufe zu begin- 
nen. 


13.4 MINIMUMS - Ein Dialog 


Das Beispiel-Programm "MINIMUMS5" demonstriert die Ver- 
wendung von Dialogen anhand einer erweiterten Version von 
MINIMUM. Wird der Menüpunkt "Über Minimum..." ausge- 
wählt, so reagiert das Programm, indem es den in Abb. 13-13 


13.4 MINIMUMS5 





Abb. 13-12 

Die Funktion Alert 
erzeugt kein Standard- 
Icon. Sie wird verwen- 
det, wenn der Alert ein 
ungewöhnliches Icon 
enthalten soll. 


GetAlrtStage 


ResetAlrtStage 
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Abb. 13-13 

Der "Über Minimum..."- 
Dialog demonstriert die 
Erzeugung und 
Verwaltung eines 
modalen Dialogs. 


gezeigten Dialog darstellt. Dieser "About-Me"-Dialog enthält 
typischerweise ein kleines Bild, einen statischen Text und einen 
Button zur Bestätigung des Dialogs. Um die Verwendung von 
Controls in einem Dialog zu demonstrieren, enthält dieser Dia- 
log weiterhin einen Radio-Button-Cluster, der die Auswahl ei- 
nes der beiden Radio-Buttons erlaubt. 


% Rbiage Bearbeiten 





Minimum. 

Ein Beispielprogramm aus dem Buch 
‘Macintosh Programmieren in C' 
Carsten Brinkschulte 1992 


Cluster 
@ Radio Button #1 
OÖ Radio Button #2 








Die Demonstration von Alerts folgt im nächsten Kapitel anhand 
des Rahmenprogramms "SKELETON". Die Erzeugung nichtmo- 
daler Dialoge wird im theoretischen Stadium belassen, da diese 
Art von Dialogen in der Regel erst in komplexeren Projekten zur 
Anwendung kommt. 


Um die Erzeugung und Verwaltung des "Über Minimum..."- 
Dialogs zu ermöglichen, wurden die folgenden Routinen modi- 
fiziert bzw. neu in den Quelltext aufgenommen: 


1. Die Funktion Init_ToolBox wurde um die Initialisierung des 
Dialog- bzw. des TextEdit-Managers erweitert. 


2. Die Funktion Do_AppleMenu wurde so erweitert, daß sie die 
Funktion Do_About aufruft, wenn der Benutzer den "Über Mi- 
nimum..."-Menüpunkt auswählt. 





3. Die neue Funktion Do_About ist für die Erzeugung und Ver- 
waltung des "Über-Minimum..."-Dialogs zuständig. Sie erzeugt 
einen modalen Dialog und reagiert auf Mausklicks in die Dia- 
logelemente. 


4. Die neue Funktion Set_ItemVal wird von Do_About aufgeru- 
fen, um einen Radio-Button ein- oder auszuschalten. Sie über- 
nimmt die Suche nach dem Dialogelement und ruft die entspre- 
chende Control-Manager-Funktion auf. 


MINIMUMS enthält einige neue Resources, die für den "Über 
Minimum..:"-Dialog benötigt werden. Diese Resources sind: 


1. Eine 'DLOG'-Resource, die die Position und Größe etc. des 
Dialogs spezifiziert: 


1: resource 'DLOG' (128) { 

2 {100, 100, 270, 485}, /* Rechteck */ 
3 dBoxProc, /* Fenstertyp */ 
4: visible, /* sichtbar? */ 
5: noGoAway, /* Schließfeld? */ 
6: 0x0, /* RefCon */ 
7 128, /* DITL-ID *) 
8: un /* Fenstertitel */ 
9: }; 


Diese 'DLOG'-Resource beginnt in Zeile 2 mit der Definition des 
umschließenden Rechtecks des Dialogfensters (in globalen Ko- 
ordinaten). 

Als Fenstertyp wurde (wie bei allen modalen Dialogen) der Typ 
dBoxProc gewählt. 

Die Konstante visible in Zeile 4 bewirkt, daß dieser Dialog so- 
fort nach der Erzeugung durch GetNewDialog sichtbar gemacht 
wird. 

In Zeile 5 wird durch die vordefinierte Konstante noGoAway 
spezifiziert, daß das Fenster kein Schließfeld haben soll (ein Fen- 
ster vom Typ dBoxProc hat nie ein Schließfeld). 

Das RefCon wird nicht verwendet, es wird daher auf den Wert 0 
gesetzt. 


13.4 MINIMUM5 





Die 'DLOG'-Resource 
beschreibt u.a. die 
Größe und Position des 
Dialogfensters. 
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In Zeile 7 wird die Resource-ID der 'DITL'-Resource spezifiziert, 
die zu diesem Dialog gehört. 

Der Fenstertitel (Zeile 8) ist leer, da ein Fenster vom Typ dBoxProc 
keinen Fenstertitel hat. 


2. Eine 'DITL'-Resource, die die Dialogelemente des Dialogs be- 


schreibt: 
Die 'DITL'-Resource 1: resource 'DITL' (128) { 
beschreibt die einzelnen 2 1. 28 [110 /* OK-Button = 
Elemente des "Über 3 {135, 287, 155, 367}, 
Minimum. .."-Dialogs. = ae 
5: enabled, 
6 . " OK " 
7 }r 
8: /* [2] */ /* Über Minimum-Text */ 
9: {10, 74, 76, 316}, 
10: StaticText { 
11% disabled, 
12: "Minimum.\nEin Beispiel-Programm 


aus dem Buch\n'Macintosh Programmieren in 
C'\nCarsten Brinkschulte 1992" 


13: }, 

14: /* [3] *%/ /* Smilie-Picture x“/ 
15: {13, 10, 63, 60}, 

16: Picture { 

17% disabled, 

18: 128 

19: In 

20: /* [4] */ /* Dreifache Umrandung */ 
21: {129, 281, 159, 371}, 

22: Picture { 

23: disabled, 

24: 129 

25: }, 

26: /* [5] %/ /* Radio 1 */ 
27: {106, 87, 124, 212}, 

28: RadioButton { 

29: enabled, 

30: "Radio Button #1" 

31: }, 

32: /* [6] */ /* Radio 2 */ 
33% {123, 87, 141, 215}, 

34: RadioButton { 
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35: enabled, 

36: "Radio Button #2" 

37: }, 

38: /* [7] %/ /* Cluster-Rahmen “/ 
39: {93, 76, 148, 225}, 

40: Picture { 

41: disabled, 

42: 130 

43: }, 

44: /* [81 %/ /* Cluster-Titel x/ 
45: {88, 84, 104, 135}, 

46: StaticText { 

47: disabled, 

48: "CJluster " 

49: } 

50: } 

515 3}7 


Die Zeilen 3 bis 7 definieren den Default-OK-Button. 

In den Zeilen 9 bis 13 wird der statische Informationstext defi- 
niert. Hier wird der Escape-Character "\" in Verbindung mit "n" 
verwendet, was einem Newline (Return) entspricht. 

Die Zeilen 15 bis 19 definieren das Smilie-Picture (in der linken 
oberen Ecke des Dialogs). Dieses Picture wurde mit MacDraw 
erstellt und könnte bei "echten" Projekten das Firmenlogo bein- 
halten. 

Durch die Zeilen 21 bis 25 wird die dreifache Umrahmung des 
OK-Buttons erzeugt. Dieses Bild wurde mit MacDraw gezeich- 
net und in ResEdit eingesetzt. 

Die Zeilen 27 bis 31 definieren den ersten Radio-Button. Die De- 
finition beginnt (wie üblich) mit der Spezifikation des um- 
schließenden Rechtecks (Zeile 27) und der Angabe des Identi- 
fikationscodes (RadioButton) in Zeile 28. 

Da der Benutzer diesen Radio-Button anklicken können soll, wird 
er in Zeile 29 durch die Verwendung der vordefinierten Kon- 
stanten enabled aktiviert. 

Der Titel des Radio-Buttons wird in Zeile 30 durch den String 
"Radio Button #1" spezifiziert. 

Die Definition des zweiten Radio-Buttons (Zeilen 32 - 37) erfolgt 
analog zur Definition des ersten. 

Da die Radio-Buttons zu einer Gruppe gehören, wird ein um- 
schließender Rahmen durch das Bild (Zeilen 39 bis 43) gezeich- 
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Abb. 13-14 

Die dreifache Umrah- 
mung des Default-OK- 
Buttons ist durch die 
nebenstehende 'PICT'- 
Resource definiert. 


| 


Abb. 13-15 

Die nebenstehende 
'PICT'-Resource enthält 
den in der Abbildung 
gezeigten Cluster- 
Rahmen. 


net. Auch diese 'PICT'-Resource wurde mit MacDraw gezeich- 
net und in ResEdit angelegt. 

Der Cluster-Titel soll über dem Rahmen liegen, so daß er den 
darunterliegenden Cluster-Rahmen verdeckt, daher folgt die 
Definition des Titels (Zeilen 45 bis 49) nach der Definition des 
Rahmens. 


3. Eine 'PICT'-Resource, die das Picture für die dreifache Um- 
randung des Default-OK-Buttons enthält: 


1: resource 'PICT' (129) { 

2: 98, 

3® {-1, -1, 29, 89}, 

4 S"0011 O2FF 0COO FFFF FFFF FFFF" 


9: 5"0064 0008 6450 726F 0000 O0OFF" 
10: }; 


Diese 'PICT'-Resource enthält in Zeile 2 zunächst die Anzahl an 
Bytes, die von diesem Picture belegt werden. 

Es folgt in Zeile 3 das umschließende Rechteck des Original-Bil- 
des. 

Die nächsten Zeilen beinhalten den 'PICT'-Opcode, der für das 
Zeichnen der dreifachen Umrahmung zuständig ist (verkürzt 
dargestellt). 


4. Eine zweite 'PICT'-Resource, die das Bild für den Cluster-Rah- 
men enthält. 


1: resource 'PICT' (130) { 

2 39, 

3: {-1, -1, 56, 164}, 

4: S"1101 A000 8201 000A FFFF FFFF" 

5 5"0038 00A4 3000 0100 0100 3800 A4A0Q" 
6 5"0083 FF" 

7: 


}37 


5. Eine dritte 'PICT'-Resource, welche das Bild des freundlichen 
Smilies beinhaltet (verkürzt dargestellt): 


l: resource 'PICT' (128) { 


2 212, 

3: {-1, -1, 74, 74}, 

4 S"1101 A000 8201 000A FFFF FFFF" 
20: S"5A0OO 5AAO 008D A000 83FF" 
21: 13 


Um mit den Routinen und Datenstrukturen des Dialog-Mana- 
gers arbeiten zu können, wurden zwei neue Header-Dateien in 
den Quelltext der Applikation aufgenommen: 


: #include <Types.h> 

: #include <Memory.h> 

: #include <QuickDraw.h> 
: #include <Fonts.h> 

: #include <Windows.h> 

: #include <Events.h> 

: #include <ToolUtils.h> 
: #include <Menus.h> 

: #include <Desk.h> 

: #include <TextEdit.h> 
: #include <Dialogs.h> 


HMHovo\ouvuPbwßrNn HH 


PR Hr 


Das #include-Statement in Zeile 10 gibt dem Compiler die Rou- 
tinen des TextEdit-Managers bekannt, der zusätzlich zum Dia- 
log-Manager initialisiert werden muß, da der Dialog-Manager 
auf Routinen und Datenstrukturen von TextEdit zurückgreift. 
Mit dem #include-Statement in Zeile 11 werden dem Compiler 
die Routinen und Datenstrukturen des Dialog-Managers bekannt 
gegeben. 


Die modifizierte Version der Funktion Init_ToolBox: 


1: void Init ToolBox (void) 

22H 

3 InitGraf ((Ptr) &qd.thePort); 
4: InitFonts (); 

5% InitWindows (); 

6: InitMenus (); 

7 TElnit (0); 

8 InitDialogs (NULL); 

9: } 
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Abb. 13-16 
Das Smilie-PICT. 


Die Liste der #include- 
Statements wurde um 
die Einbindung der 
Interface-Dateien des 
Dialog- und des 
TextEdit-Managers 
erweitert. 


Init_TooIBox initialisiert 
Jetzt den TextEdit- und 
den Dialog-Manager. 
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Do_AppleMenu reagiert 
jetzt auf die Auswahl des 
Menüpunktes "Über 
Minimum. ..', indem die 
Funktion Do_About 
aufgerufen wird. 


Die Funktion Init_ToolBox initialisiert in Zeile 7 durch den Auf- 
ruf der TextEdit-Manager-Funktion TElnit die Datenstrukturen 
dieses Managers. 

In Zeile 8 wird der Dialog-Manager durch den Aufruf der Funk- 
tion InitDialogs initialisiert. Hier wird der Wert NULL anstelle 
des geforderten Funktions-Pointers übergeben, da die Möglich- 
keit einer "System-Error-Abfang-Routine" noch nicht verwendet 
wird. 


Die modifizierte Version der Funktion Do_AppleMenu: 


1: void Do_AppleMenu (short menultem) 
2 dt 

3 short daRefNum; 

4: Str255 daName; 
nm 
6 

7 

8 


switch (menultem) 
{ 
: case iAbout: 
9: Do About (); 


10: break; 

11% 

12: default: 

13: GetItem (GetMHandle (mApple), 
menultem, daName); 

14: daRefNum = OpenDeskAcc (daName); 

15% break; 

le: } 

17: } 


Die erweiterte Version von Do_AppleMenu reagiert in den Zei- 
len 8bis 10 auf die Auswahl des "Über Minimum. . ."-Menüpunktes, 
indem die Funktion Do_About aufgerufen wird. Diese Funktion 
ist für die Erzeugung und Verwaltung des "Über Minimum..."- 
Dialogs verantwortlich. 


Die neue Funktion Do_About: 


1: void Do About (void) 
2er 

3: #define dOKButton 1 
4 #define dRadiol 5 


#define dRadio2 6 


5 

6: 

7: short itemHit; 
8: DialogPtr theDialog; 
9 
0 


1 theDialog = GetNewDialog (128, NULL, 
(windowPtr) -1); 

14:5: Set _ItemVal (theDialog, dRadiol, 1); 

12: do 

1:3: { 

14: ModalDialog (NULL, &itemHit); 

15: switch (itemHit) 

16: { 

17: case dRadiol: 

18: Set_ItemVal (theDialog,dRadio2,0); 

19: Set_ItemVal (theDialog,dRadiol,1); 

20: break; 

21: 

22: case dRadio2: 

23: Set_ItemVal (theDialog,dRadiol,0); 

24: Set_ItemVal (theDialog,dRadio2,1); 

238 break; 

26: } 

27: } 

28: while (itemHit != dOKButton); 

29 DisposeDialog (theDialog); 


Die Funktion beginnt mit der Definition von drei lokalen Kon- 
stanten (dOKButton, dRadiol, dRadio2), die den jeweiligen 
Nummern der Dialogelemente entsprechen und für den Zugriff 
auf die Elemente verwendet werden. 

In Zeile 10 wird der Dialog erzeugt, indem GetNewDialog auf- 
gerufen wird. Der Funktion GetNewDialog wird die Resource- 
ID der 'DLOG'-Resource übergeben, welche die Beschreibung des 
Dialogfensters und einen Verweis auf die zugehörige 'DITL’- 
Resource enthält. Da anstelle des Parameters wStorage der Wert 
NULL übergeben wird, legt GetNewDialog einen nonrelocatable- 
Block im Speicherbereich der Applikation an, um den Dialog zu 
verwalten. Dies ist bei einem modalen Dialog vertretbar, da der 
nonrelocatable-Block kurze Zeit später wieder freigegeben wird 
und daher nicht zu einer permanenten Fragmentierung des 
Speicherbereichs führt. Mit dem letzten Parameter, der an 
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Do_About erzeugt den 
Über Minimum...'- 
Dialog und reagiert auf 
die Auswahl der Radio- 
Buttons. 


Cluster 

| ® Radio Button #1 | 
O Radio Button #2 
Cluster 

| O Radio Button #1 
® Radio Button #2 


Abb. 13-17 

Wird einer der beiden 
Radio-Buttons ange- 
klickt, so wird dieser 
Radio-Button ein- und 
der andere ausgeschal- 
tet. 
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Um die Werte der 
Radio-Buttons zu 
verändern, wird die 
Funktion Set_ltemVal 
aufgerufen. 


Dialogfenster über allen bereits bestehenden Fenstern erzeugt 
wird. Bei der Übergabe dieses Wertes wird Type-Casting ver- 
wendet, um die Zahl (-1) in den geforderten Typ (WindowPtr) 
umzuwandeln. Der Ergebniswert der Funktion GetNewDialog 
wird in der lokalen Variablen theDialog abgelegt, um für spä- 
tere Zugriffe auf den Dialog zur Verfügung zu stehen. 

In Zeile 11 wird die neue Funktion Set_ItemVal verwendet, um 
den ersten Radio-Button initial einzuschalten. Diese Funktion sucht 
ein Dialogelement aus einem Dialog heraus und verwendet eine 
Control-Manager-Funktion, um den Wert des Controls zu setzen. 
Diese Funktion bekommt als ersten Parameter die Adresse des 
Dialogs, in welchem sich das zu verändernde Element befindet. 
Der zweite Parameter spezifiziert die Elementnummer des ge- 
suchten Elements, der dritte Parameter gibt den Wert an, auf den 
das Element gesetzt werden soll. 

Die Zeilen 12 bis 28 enthalten die Schleife, die für die Abarbei- 
tung des modalen Dialogs zuständig ist. Diese Schleife läuft so- 
lange, bis der Benutzer den OK-Button auswählt, um den Dialog 
zu beenden. 

In Zeile 14 wird in jedem Durchlauf zunächst die Funktion 
ModalDialog aufgerufen, um auf die Auswahl des Benutzers zu 
warten. Da in diesem einfachen Dialog keine Filterroutine ver- 
wendet wird, wird anstelle des Funktions-Pointers der Wert NULL 
übergeben. Der zweite Parameter, der an ModalDialog überge- 
ben wird, ist die Adresse der lokalen Variablen itemHit, in wel- 
cher ModalDialog die Nummer des getroffenen Dialogelements 
spezifiziert. 

Die Zeilen 15 bis 26 reagieren mit einer switch-Anweisung über 
den Wert von itemHit auf die Auswahl des Benutzers. Je nachdem, 
welcher Radio-Button angeklickt wurde, wird der eine aus-, der 
andere eingeschaltet. 

Hat der Benutzer auf den Radio-Button #1 geklickt, so wird der 
Wert dieses Radio-Buttons auf 1, der Wert des anderen auf 0 gesetzt 
(Zeile 18 und 19). 

Die Zeilen 23 und 24 reagieren auf die Auswahl des Radio-Buttons 
#2, indem der zweite Radio-Button ein- und der erste ausgeschaltet 
wird. 
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Wenn die Schleife terminiert (der Benutzer hat auf den OK-Button 
geklickt), so wird der Dialog in Zeile 29 durch den Aufruf der 
Funktion DisposeDialog geschlossen und der belegte Speicher- 
platz freigegeben. 


Die neue Funktion Set_ItemVal: 


1: void Set_ItemVal ( DialogPtr theDialog, Set_ItemVal sucht ein 
short itemNo, Dialogelement aus 
3 short value) einer Dialog heraus 
ni , und setzt den Wert 
3% short itemType; . e 
2: Händie ir eis dieses Elements. Diese 
5: Rect box; Funktion darf nur für 
6: Dialogelemente 
u GetDItem (theDialog, itemNo, &itemType, verwendet werden, die 
&item, &box); zum Control-Manager 
8: SetCtlValue ((ControlHandle) item, value); R ; 
9: gehören (z.B. Radio- 


Buttons). 


Die Funktion Set_ItemVal ist eine Utility-Routine, die verwen- 
det werden kann, um den Wert eines Dialogelements zu verän- 
dern. Dabei wird vorausgesetzt, daß es sich bei diesem Element 
um einen Control (Radio-Button, Check-Box etc.) handelt. Diese 
Funktion darf also nicht für andere Dialogelemente aufgerufen 
werden (dies würde zu einem Programmabsturz führen). 
Wenn die Funktion Set_ItemVal aufgerufen wird, so enthält der 
übergebene Parameter theDialog die Adresse des Dialogs, in 
welchem sich der gesuchte Control befindet. Der Parameter itemNo 
enthält die Nummer des Dialogelements (des Controls). Der Pa- 
rameter value ist der Wert, auf den der Control gesetzt werden 
soll. 

In Zeile 7 wird zunächst die Funktion GetDlItem verwendet, um 
eine Referenz auf das Dialogelement (den Handle) zu erhalten. 
Dieser Funktion wird die Variable theDialog übergeben, um zu 
spezifizieren, in welchem Dialog sich das gesuchte Element be- 
findet. Der zweite Parameter (itemNo) spezifiziert die Nummer 
des gesuchten Dialogelements. In den folgenden drei Parame- 
tern liefert GetDItem Ergebniswerte zurück. Der Elementtyp wird 
in itemType abgelegt, die Variable item enthält den Handle auf 
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a, das Dialogelement und die Variable box das umschließende 
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Rechteck des Dialogelements. 

Der Handle auf das Dialogelement (item) ist hier der einzig 
wichtige Ergebniswert. Er wird in Zeile 8 mit Hilfe von Type- 
Casting in einen ControlHandle verwandelt, um ihn an die Control- 
Manager-Funktion SetCtlValue zu übergeben. SetCtlValue 
verändert den Wert des übergebenen Controls und sorgt dafür, 
daß dieser Control neugezeichnet wird. Der neue Wert für die- 
sen Control wird durch den Parameter value spezifiziert. 


ETC 


Das Programm 
SKELETON 


Dieses Kapitel beschreibt und analysiert das Beispiel-Programm 
SKELETON, welches einen kompletten Rahmen für komplexere 
Projekte zur Verfügung stellt. Dieses Rahmenprogramm enthält 
nahezu alle wichtigen Funktionalitäten eines Macintosh-Pro- 
gramms und bildet daher eine solide Basis für "echte" Projekte. 
Zunächst wird ein Überblick über die neuen Konzepte bzw. 
Funktionalitäten des Programms gegeben. Der zweite Teil des 
Kapitels beschreibt das neue Datenverwaltungskonzept von 
Skeleton bzw. die Datenstrukturen, die für die Implementierung 
dieses Konzeptes verwendet werden. Der dritte Teil beschreibt 
die neuen und geänderten Funktionen, der vierte Teil enthält 
den kompletten Quelltext des Programms. 


Skeleton baut (selbstverständlich) auf den vorangegangenen 
Beispiel-Programmen der MINIMUM-Serie auf. Es enthält jedoch 
einige konzeptionelle Verbesserungen sowie neue Funktionalitäten. 
Die neuen Funktionalitäten bzw. Verbesserungen von Skeleton 
sind: 


1. Das Konzept "Dokument". 

Bisher wurde nur die Verwaltung von Fenstern, Menüs und 
Dialogen erläutert - die Datenverwaltung wurde etwas ver- 
nachlässigt. Skeleton führt das Datenverwaltungskonzept der 
Dokumente ein, in welchem Fenster, Scrollbars und Daten zu 
einer Datenstruktur zusammengefaßt werden. 
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Abb. 14-1 

Das Beispielprogramm 
Skeleton ist in der Lage, 
mit mehreren Fenstern 
bzw. Dokumenten zu 
arbeiten. 


2. Mehrere Dokumente. 

Skeleton kann (wie eine "echte" Macintosh-Applikation) mit 
mehreren Dokumenten bzw. Fenstern arbeiten. Wenn der Benutzer 
den Menüpunkt "Neu" aus dem "Ablage"-Menü auswählt, so 
erzeugt Skeleton ein neues Fenster. 





& EETTETTEM Bearbeiten 
Öffnen... 
Schließen 
Sichern 


Sichern unter... 


Seitenformat... 
Drucken... 3#P 


Beenden *0 








3. /O-Schnittstelle. 

Die Funktionalität des Programms wurde so erweitert, daß Do- 
kumente gesichert bzw. wieder gelesen werden können. Skeleton 
reagiert auf die Auswahl des "Sichern unter..."-Menüpunktes aus 
dem "Ablage"-Menü, indem es den üblichen Sichern-Dialog erzeugt 
und anschließend die Daten des Dokuments in einer neu angelegten 
Datei ablegt. Wenn der "Öffnen..."-Menüpunkt ausgewählt wird, 
so kann der Benutzer in dem üblichen Öffnen-Dialog eine Datei 
auswählen, auf deren Grundlage ein neues Dokument erzeugt 
wird. 


14 Das Beispiel- 


programm SKELETON 





% Rbinge Bearbeiten 


Ohne Titel 








Abb. 14-2 
Skeleton kann die Daten 
Bünse Tief (as n a ee 
osition des Kreises) in 
eine Datei speichern 
[© bzw. aus einer Datei 
Sichern unter: lesen. 
4. User-Interaktion. 
Skeleton bietet die Möglichkeit, die Daten des Dokuments (die 
Position des Kreises im Dokument) mit Hilfe der Maus zu verän- 
dern und demonstriert dabei die grundlegende Technik des Mouse- 
Trackings. 
% Ablage Bearbeiten Abb. 14-3 
| Dane Tine) Der Benutzer kann den 
Kreis verschieben, 
indem er in den Kreis 
klickt und die Maus- 
position bei gedrückter 
Maustaste verschiebt. 
Wenn die Mausposition 


verschoben wird, folgt 
Skeleton, indem der 
Kreis jeweils an der 
aktuellen Mausposition 
gezeichnet wird. 





5. "Sichere" Datenverwaltung. 

Wenn der Benutzer ein Dokument schließen will, dessen Daten 
verändert worden sind, so wird der Benutzer mit Hilfe eines Warn- 
Alerts gefragt, ob er die Änderungen sichern oder verwerfen 


möchte. 
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Abb. 14-4 

Skeleton verwendet 
einen Alert, um den 
Benutzer zu warnen, 
wenn er ein Dokument 
schließen will, dessen 
Daten modifiziert 
worden sind. 


Die Datenstruktur 
Document stellt eine 
eindeutige Beziehung 

zwischen der 
Dokumentdaten, dem 
Fenster und den 
Fensterelementen her. 
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14.1 Neue Datenstrukturen 


Die bisherigen Beispiel-Programme der MINIMUM-Serie sind 
zwar (im Prinzip) bereits auf die Verwaltung mehrerer Fenster 
ausgelegt, dieser wichtigen Funktionalität standen jedoch noch 
konzeptionelle Mängel entgegen. Skeleton führt das Konzept der 
Dokumente ein, um diese Mängel zu beheben. Ein Dokument ist 
eine Datenstruktur, welche Fenster, Scrollbars und Daten zu einer 
Struktur zusammenfaßt. 

Die Document-Struktur ist wie folgt deklariert: 


1: struct Document { 

2 WindowRecord theWindow; 

33 ControlHandle vertScrollbar, 
4: horizScrollbar; 
5% Boolean inUse, 

6 hasBeenChanged; 
7 hasBeenSaved; 

8 SFReply reply; 

9: Rect documentData; 
10: }; 


11T; 
12: typedef struct Document Document; 
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13: typedef Document *DocumentPtr; 
14: 
15: #define kMaxDocuments 10 Skeleton kann bis zu 10 
16: Fenster gleichzeitig 
17: Document gDocuments [kMaxDocuments]; verwalten 
18: short gCountDocuments; 


Das erste Feld eines Document-structs ist ein WindowRecord, 

welcher zur Verwaltung des Fensters verwendet wird. Skeleton 

legt den Datenblock, der zur Verwaltung eines Fensters benötigt 

wird, nicht mehr dynamisch an (indem ein nonrelocatable-Block 

erzeugt wird), sondern verwendet stattdessen den WindowRecord 

eines Document-structs. Dies wird nötig, da Skeleton in der Lage 

ist, Dokumente bzw. Fenster zur Laufzeit des Programms anzu- 

legen bzw. wieder freizugeben, was zu einer Fragmentierung des 

Speicherbereichs führen würde, wenn der WindowRecord in ei- 

nem nonrelocatable-Block angelegt würde. 

Der WindowRecord steht an erster Stelle im Document-struct, Da das erste Feld des 
damit ein WindowPtr (Adresse des WindowRecords) mit Hilfe Document-structs ein 
von Type-Casting in einen DocumentPtr umgewandelt werden WindowRecord ist, 
kann (und umgekehrt). Diese Strukturierung erleichtert die Ar- entspricht die Adresse 
beit mit Dokumenten bzw. Fenstern, damanoftvoneinemFenster eines Document-structs 
(WindowPtr) zu den Daten dieses Fensters (DocumentPtr) gelangen (DocumentPtr) der eines 
möchte. WindowRecords 
Die zu dem Fenster gehörenden Scrollbars werden mit den bei-  (WindowPtr). 

den ControlHandles (vertScrollbar und horizScrollbar) ver- 

waltet. 

Jedes Dokument enthält einen Boolean (inUse), an welchem er- 

kannt werden kann, ob der Document-struct benutzt wird, oder 

ober für die Erzeugung eines neuen Dokuments verwendet werden 

kann. 

Da der Benutzer die Daten eines Dokuments verändern kann (er 

kann den Kreis verschieben), muß Skeleton erkennen können, 

ob die Daten modifiziert worden sind. Dies wird dann wichtig, 

wenn der Benutzer das Dokument schließen möchte oder die 

Applikation beendet. Skeleton muß in diesen Situationen einen 

Dialog darstellen, in welchem der Benutzer gefragt wird, ob die 

Modifikationen gesichert oder verworfen werden sollen. Um zu 

erkennen, ob ein Dokument modifiziert worden ist, verwaltet 
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Die Informationen, ob 
die Dokumentdaten 
geändert worden sind, 
oder ob das Dokument 
selbst schon einmal 
gesichert worden ist, 
sind im Dokument 
selbst enthalten. 


Das Dokument enthält 
einen Verweis auf die 
zugehörige Datei. 


das Programm den Boolean hasBeenChanged, welcher den Wert 
true enthält, wenn das Dokument verändert worden ist. 

Wenn der Benutzer den Menüpunkt "Sichern" aus dem "Abla- 
ge"-Menü auswählt, so untersucht Skeleton den Boolean 
hasBeenSaved, um festzustellen, ob das Dokument bereits gesi- 
chert worden ist oder nicht. Wurde das Dokument noch nie ge- 
sichert, so wird der übliche Sichern-Dialog erzeugt, in welchem 
der Benutzer den Dateinamen eingeben und die Position im 
Dateisystem auswählen kann. Hat er das Dokument schon einmal 
gesichert, so wird das Dokument (ohne den Dialog zu zeigen) 
erneut in die verbundene Datei gespeichert. 

Wenn der Benutzer das Dokument schon einmal gesichert hat, 
so enthält das Feld reply in Zeile 8 Informationen über die zu 
diesem Dokument gehörende Datei (Dateinamen, Position im File- 
System etc...). 

Die Dokumentdaten sind in dem Feld documentData enthalten. 
In diesem Rahmenprogramm enthält dieses Feld lediglich das 
umschließende Rechteck des Kreises, welcher im Fenster dargestellt 
wird. Bei "echten" Projekten könnte hier ein Array oder ein Handle 
auf weiter verzweigende Datenstrukturen existieren. 


Skeleton ist (wie beschrieben) in der Lage, mehrere Dokumente 
zu verwalten. Die einzelnen Dokumente sind in einem globalen 
Array (gDocuments) enthalten, so daß jederzeit direkter Zugriff 
auf diese Datenstrukturen existiert. Die Anzahl der Dokumente, 
die gleichzeitig geöffnet sein können, ist durch diese Technik zwar 
auf eine maximale Zahl beschränkt, verhindert jedoch (wie be- 
schrieben) eine permanente Fragmentierung des Speicherbereichs 
durch nonrelocatable-Blocks. 


Die Anzahl der geöffneten Dokumente ist in der Variablen 
gCountDocuments enthalten. An dieser Variablen kann erkannt 
werden, ob noch ein weiteres Dokument erzeugt werden kann 
oder ob die maximale Anzahl bereits erreicht ist. 


14.2 Neue und geänderte Funktionen 


Um die neuen Konzepte und Funktionalitäten von Skeleton zu 
implementieren, wurden die folgenden Routinen modifiziert oder 
neu in den Quelltext aufgenommen: 


1. Die neue Funktion Initialize faßt die Aufrufe von Init_ToolBox 
und Make_Menus (die bisher von main gemacht wurden) mit 
der Initialisierung der globalen Dokumentstrukturen zusammen. 
Initialize wird von main aufgerufen und übernimmt (neben der 
Initialisierung) die Erzeugung eines neuen Fensters. 


2. Die Funktion Do_FileMenu, welche auf eine Menüpunktaus- 
wahl aus dem "Ablage"-Menü reagiert, wurde so erweitert, daß 
die Menüpunkte "Neu", "Öffnen...", "Sichern", "Sicher unter..." 
und "Schließen" unterstützt werden. Do_FileMenu ruft die ent- 
sprechenden Aktionsroutinen auf, wenn einer dieser Menüpunkte 
ausgewählt wird. 


3. Die neue Funktion Do_Open wird aufgerufen, wenn der Be- 
nutzer den "Öffnen..."-Menüpunkt aus dem "Ablage"-Menü 
auswählt. Sie erzeugt den üblichen Öffnen-Dialog und läßt den 
Benutzer eine Datei auswählen, um anschließend ein neues Do- 
kument auf der Basis dieser Datei zu erzeugen. 


4. Die neue Funktion Do_New übernimmt die Erzeugung eines 
neuen Dokuments. Diese Routine erzeugt ein neues Fenster bzw. 
die zugehörigen Elemente (z.B. die Scrollbars). Sie wird aufgerufen, 
wenn der Benutzer den Menüpunkt "Neu" aus dem "Ablage"- 
Menü auswählt, oder ein Dokument von der Festplatte öffnet 
("Ablage"-"Öffnen..."-Menüpunkt). 


5. Do_SaveAs ist eine neue Funktion, die aufgerufen wird, wenn 
der Benutzer den Menüpunkt "Sichern unter..." auswählt. Sie 
erzeugt den üblichen Sichern-Dialog, und läßt den Benutzer ei- 
nen Dateinamen eingeben bzw. den Pfad zum Speichern des 
Dokuments auswählen. Sie erzeugt eine neue Datei und ruft die 
Funktion Save_Document auf. 


14.2 Neue und 
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6. Die neue Funktion Save_Document wird aufgerufen, um die 
Dokumentdaten zu sichern. Sie speichert die Daten des Dokuments 
in die (bereits angelegte) Datei. 


7. Die neue Funktion Do_Save wird aufgerufen, wenn der Be- 
nutzer den "Sichern"-Menüpunkt aus dem "Ablage"-Menü aus- 
wählt. Diese Funktion analysiert das Dokument des aktiven 
Fensters, um zu entscheiden, welche Aktionen durchgeführt 
werden sollen. Möchte der Benutzer ein Dokument sichern, welches 
noch nie gespeichert wurde, so ruft sie Do_SaveAs auf. Ist das 
Dokument schon einmal gesichert worden, so wird die Funktion 
Save_Document aufgerufen. 


8. Die Funktion Do_CloseWindow wurde so modifiziert, daß sie 
Do_Close aufruft, wenn der Benutzer das Fenster schließen will. 


9. Die neue Funktion Do_Close untersucht, ob die Daten des 
Dokuments modifiziert worden sind. Sind die Daten geändert 
worden, so erzeugt sie einen Alert, in welchem der Benutzer 
auswählen kann, ob er die Änderungen des Dokuments speichern 
oder verwerfen möchte. Je nach Auswahl des Benutzers bzw. 
Zustand des Dokuments ruft sie Do_SaveAs oderSave_Document 
auf oder schließt das Dokument, ohne die Daten zu sichern. 


10. Die Funktion Do_Quit wurde so erweitert, daß sie vor Been- 
digung des Programms Do_Close für jedes geöffnete Dokument 
aufruft, um sicherzustellen, daß der Benutzer eventuell verän- 
derte Dokumente sichern kann, bevor das Programm beendet 
wird. 


11. Die neue Funktion Adjust_Menus wird immer dann aufge- 
rufen, wenn der Benutzer in die Menüleiste klickt oder einen 
Menükurzbefehl ausführen will. Diese Funktion aktiviert oder 
deaktiviert dieeinzelnen Menüpunkte (jenach Programmzustand). 
Sind beispielsweise alle Document-structs belegt, so wird der 
"Neu"- und der "Öffnen..."-Menüpunkt aus dem "Ablage"-Menü 
deaktiviert, so daß der Benutzer diese Menüpunkte nicht aus- 
wählen kann. 


14.2 Neue und 


geänderte Funktionen 





12. Die Funktion Do_GraphicsClick wurde so erweitert, daß sie 
dem Benutzer die Möglichkeit gibt, den Kreis (der sich im Fen- 
ster befindet) zu verschieben. Sie stellt fest, ob der Mausklick im 
inneren Bereich des Kreises liegt und folgt dann den Mausbe- 
wegungen, um anschließend die Dokumentdaten entsprechend 
zu verändern. 


13. Die neue Funktion Track_Oval wird von Do_GraphicsClick 
aufgerufen, um die Mausbewegungen zu verfolgen und so eine 
Verschiebung des Kreises zu ermöglichen. 


14. Die Funktion Draw_Graphics wurde so modifiziert, daß sie 
den Kreis an der Position zeichnet, welche im Document-struct 
enthalten ist. 


15. Die Funktion Get_ContentSize wurde so modifiziert, daß sie 
die Verschiebung des Kreises berücksichtigt. Durch die Ände- 
rungen werden die Scrollbars automatisch aktiviert, wenn der 
Benutzer den Kreis so verschiebt, daß Teile unsichtbar werden. 


Set_WindowEnv 









Do_Update 





Set_DrawingEnv 





Init_TooiBox 










Draw_Graphics 








Make_Menus 








Initialize 
T 






























































Make_Document Do_GrowWindow Pe Recalc_Scrollbars |—»{| Get_ContentSize 
[ Do_ZoomWindow | Do_GraphicsClick }—>J__Track_Oval 
( | __Do_Event Do_MouseDown Do_ContentClick Scroll_Graphics 
' Do_DragWindow Scroll_Proc u — Do_Scroll H—>- Scroll_Scrollbar 








Do_CloseWindow ——| Do_Close 











Adjust_Menus 











Do_AppleMenu ——| Do_About 








Do_KeyDown Do_MenuCommand 
















Do_Activate 





er Save_Document 





Do_FileMenu 














Abb. 14-5 
Der interne Kontrollfiuß 
von Skeleton. 329 


Kapitel 14 


Skeleton 





Um die Selbstdokumentation des Quelltextes zu erhöhen, wur- 
den Konstanten eingeführt, die anstelle der Resource-IDs bei 
Zugriffen auf Resources verwendet werden: 


Die Resource-ID- #define rWindow 128 
Konstanten beginnen #define rHScrollbar 128 
mit *r* (für Resource‘). #define rVScrollbar 129 
#define rMenuBar 128 

#define rAboutDialog 128 


#define rSaveChangesAlert 129 


Die neue Funktion Initialize: 


Initialize initialisiert die 
globalen Variablen und 
koordiniert den weiteren 
Initialisierungsprozeß. 


short i; 


gCountDocuments = 0; 
for (i = 0; i < kMaxDocuments; i++) 


I 
2 
3 
4: 
9: gQuit = false; 
6: 
7 
8 gDocuments[i].inUse = false; 


10: Init_ToolBox (); 

14: Make Menus (); 

12: Do_ New (); 

13: SetCursor (&qd.arrow); 
14: } 


Initialize übernimmt zunächst die Initialisierung der globalen 
Datenstrukturen (Zeilen 5 - 8). Die Initialisierung des globalen 
Document-Arrays wird in Zeile 7 bzw. 8 durch das Setzen des 
inUse-Flags erledigt. An diesem inUse-Flag erkennen andere 
Funktionen, ob der Document-struct belegt ist oder zur Erzeugung 
eines neuen Dokuments verwendet werden kann. 

Die Zeilen 10 und 11 sorgen für die Initialisierung der ToolBox 
sowie für die Erzeugung der Menüs, indem Init_ToolBox bzw. 
Make_Menus aufgerufen wird. 

In Zeile 12 wird die neue Funktion Do_New aufgerufen, um das 
initiale Dokument zu erzeugen. 
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Die neue Funktion Do_New: 


1: DocumentPtr Do_New (void) 
PIRER | 
33 short i=0; 
4: WindowPtr theWindow; 
5: 
6: for (i = 0; i < kMaxDocuments; i++) 
Er { 
8: if (gDocuments[i].inUse == false) 
9: { 
10: theWindow = GetNewWindow (rWindow, 
&gDocuments[i], (WindowPtr) -1); 
le SetPort (theWindow) ; 
12: gDocuments[i].vertScrollbar = 
GetNewControl (rVScrollbar, 
theWindow) ; 
133 gDocuments[i].horizScrollbar = 
GetNewControl (rHScrollbar, 
theWindow) ; 
14: gDocuments[i].inUse = true; 
15: gDocuments[i].hasBeenChanged = false; 
16: gDocüuments[i].hasBeenSaved = false; 
17: SetRect (&qDocuments[i].documentData, 
10, 10, 210, 210); 
18: gCountDocumentst+; 
19: return &gDocuments[i]; 
20: } 
21: } 
22: return NULL; 
23: } 


Do_New durchsucht den globalen Document-Array nach einem 
Dokument, welches noch nicht in Gebrauch (inUse) ist. Dies 
geschieht, indem innerhalb der for-Schleife (Zeilen 6 bis 21) das 
inUse-Feld des aktuellen Document-structs untersucht wird, bis 
ein Dokument gefunden wird, welches noch nicht in Gebrauch 
ist. Ist ein unbenutztes Document-struct gefunden, so wird in 
Zeile 10 ein neues Fenster mit Hilfe der Funktion GetNewWindow 
erzeugt. Bei dem Aufruf dieser Funktion wird die Adresse des 
Document-structs übergeben, so daß GetNewWindow den 
WindowRecord des Document-structs verwendet, um das Fen- 
ster zu verwalten. Auf diese Weise wird vermieden, daß 


14.2 Neue und 


geänderte Funktionen 





Do_New erzeugt ein 
neues Dokument. Diese 
Funktion durchsucht die 
Liste der Dokumente 
nach einem Document- 
struct, welches noch 
nicht benutzt wird und 
verwendet diese 
Struktur, um ein neues 
Fenster bzw. die 
zugehörigen Fenster- 
elemente zu verwalten. 


Bei der Erzeugung des 
Fensters wird auf die 
Alloziierung eines 
Nonrelocatable-Blocks 
verzichtet, um eine 
permanente Fragmentie- 
rung des Speicher- 
bereiches zu verhindern. 
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Adjust_Menus aktiviert 
bzw. deaktiviert die 
Menüpunkte des 
"Ablage'-Menüs, so daß 
nur die Menüpunkte zur 
Verfügung stehen, die in 
der aktuellen 
Programmsituation 
verwendet werden 
können. 


GetNewWindow einen nonrelocatable-Block anlegt und damit 
den Speicherbereich fragmentiert. 

In Zeile 11 wird die aktuelle Zeichenumgebung auf das neue Fenster 
geschaltet, da dieses nun das oberste Fenster ist. 

In den Zeilen 12 und 13 werden die Scrollbars für das neue Fen- 
ster erzeugt, indem GetNewControl aufgerufen wird. Die 
ControlHandles der Scrollbars werden im Document-struct ab- 
gelegt, so daß eine eindeutige Zuordnung zwischen dem Fenster 
und den Scrollbars entsteht. 

In den Zeilen 14 bis 16 werden die Flags des Document-structs 
auf ihren initialen Wert gesetzt. 

Zeile 17 initialisiert die Daten des Dokuments (Koordinaten des 
Kreises). Hier würde bei komplexeren Projekten die Initialisie- 
rung der Datenstrukturen oder die Alloziierung eines Handles 
zur Verwaltung der Daten stattfinden. 

Zeile 18 erhöht die globale Variable gCountDocuments, welche 
die Anzahl der benutzten Dokumente enthält. 

In Zeile 19 wird die Adresse des Dokuments als Ergebniswert 
zurückgegeben. 

Wenn die Suche nach einem unbenutzten Document-struct er- 
folglos war, so wird in Zeile 22 der Wert NULL als Ergebniswert 
zurückgegeben, um auf den Fehler hinzuweisen. 


Die neue Funktion Adjust_Menus: 


1: void Adjust_Menus (void) 

Pr 

30 MenuHandle theMenu; 

4: WindowPtr theWindow; 

Di DocumentPtr theDocument; 

6 

7 /* "Ablage"-Menüelemente */ 

8: 

9: theMenu = GetMHandle (mFile); 
10: i£ (gCountDocuments < kMaxDocuments) 
Da { 

12: EnableItem (theMenu, iNew); 
135 EnableItem (theMenu, iOpen); 
14: } 

15% else 

16: { 

17: DisableItem (theMenu, iNew); 


18: DisableItem (theMenu, iOpen); 

19: } 

20: 

21: if (gCountDocuments > 0) 

22: { 

23: EnableItem (theMenu, iSaveAs); 

24: EnableItem (theMenu, iClose); 

25% 

26: theWindow = FrontWindow (); 

27: theDocument = (DocumentPtr) theWindow; 
28: if (theDocument->hasBeenChanged | | 


(!theDocument->hasBeenChanged && 
!theDocument->hasBeenSaved) ) 


29: EnableItem (theMenu, iSave); 
30: else 

31% DisableIltem (theMenu, iSave); 
323 } 

33% else 

34: { 

39% DisableIltem (theMenu, iSave); 
36: DisableItem (theMenu, iSaveAs); 
37: DisableItem (theMenu, iClose); 
38: } 

39: 


40: if (Is_DAWindow (FrontWindow ())) 
41: { 


42: DisableItem (theMenu, iNew); 
43: DisableItem (theMenu, iOpen); 
44: EnableItem (theMenu, iClose); 
45: Disableltem (theMenu, iSave); 
46: DisableItem (theMenu, iSaveAs); 
41: DisableItem (theMenu, iSaveAs); 
48: } 

49: } 


Diese Funktion wird aufgerufen, bevor der Benutzer einen 
Menüpunkt auswählen kann (beispielsweise von der Funktion 
Do_MouseCommand, wenn diese einen Klick in die Menüleiste 
feststellt). Ihre Aufgabe ist es, die Menüpunkte (den gegebenen 
Umständen entsprechend) zu aktivieren oder zu deaktivieren. 

In der derzeitigen Version kümmert sich diese Funktion aus- 
schließlich um die Menüpunkte des "Ablage"-Menüs. Bei einem 
"echten" Projekt müßte diese Funktion aufgesplittet werden, um 
auch andere Menüs (z.B. das "Bearbeiten"-Menü) zu unterstützen. 


14.2 Neue und 
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Die Menüpunkte 
‘Sichern unter...", 
'Schließen" und 
"Sichern" sind abhängig 
von der Anzahl der 
geöffneten Dokumente 
bzw. des Zustands des 
vordersten Dokuments. 


Wenn das vorderste 
Fenster zu einem 
Schreibtischprogramm 
gehört, dann darf nur 
der Menüpunkt 
"Schließen" zur Verfü- 
gung stehen. 
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In Zeile 9 wird die Menu-Manager-Funktion GetMHandle ver- 
wendet, um einen Handle auf das "Ablage"-Menü zu erhalten. 
Dieser MenuHandle wird im Folgenden verwendet, um die ein- 
zelnen Menüpunkte zu aktivieren bzw. zu deaktivieren. 

Wenn die maximale Anzahl der geöffneten Dokumente noch nicht 
erreicht ist, so werden die beiden Menüpunkte, mit denen ein 
neues Dokument erzeugt werden kann ("Neu" und "Öffnen"), in 
Zeile 12 und 13 aktiviert. Anderenfalls werden sie in den Zeilen 
17 und 18 deaktiviert. 

Die Zeilen 21 bis 38 kümmern sich um die Menüpunkte "Sichern", 
"Sichern unter..." und "Schließen". Wenn mindestens ein Doku- 
ment geöffnet ist, so können die Menüpunkte "Sichern unter..." 
und "Schließen" verwendet werden. Sie werden in Zeile 22 und 
23 aktiviert. 

Um herauszufinden, ob der "Sichern"-Menüpunkt aktiviert wer- 
den soll, muß der Zustand des Dokuments untersucht werden, 
welches zum obersten Fenster gehört. Zeile 26 fragt den Window- 
Manager zunächst nach dem obersten Fenster, indem die Funk- 
tion FrontWindow aufgerufen wird. Da ein WindowPtr (Adres- 
se des WindowRecords) wie die Adresse des zugehörigen 
Documents behandelt werden kann, wird der WindowPtr 
theWindow in Zeile 27 mit Hilfe von Type-Casting in einen 
DocumentPtr verwandelt. 

Ob der Menüpunkt "Sichern" aktiviert werden kann, hängt da- 
von ab, ob das Dokument bereits gesichert wurde und ob die 
Daten dieses Dokuments verändert worden sind. Wenn das Do- 
kument geändert wurde oder nicht geändert, aber noch nie ge- 
sichert wurde, so wird der Menüpunkt "Sichern" in Zeile 29 ak- 
tiviert. Anderenfalls wird der Menüpunkt in Zeile 31 deaktiviert. 
Wenn kein Dokument geöffnet ist, so kann weder der "Sichern"- 
‚ noch der "Sichern unter..."-, noch der "Schließen"-Menüpunkt 
ausgewählt werden, diese Menüpunkte werden dann deaktiviert 
(Zeilen 35 -37). 

Wenn das Programm unter System 6 im Single-Finder läuft und 
das oberste Fenster ein DA (Schreibtischprogramm)-Fenster ist, 
so sollten sämtliche Menüpunkte des "Ablage"-Menüs deaktiviert 
werden (Zeilen 42 - 47), da der Benutzer mit dem Schreibtisch- 
programm arbeiten möchte. Nur der Menüpunkt "Schließen" sollte 
aktiv bleiben, damit das DA über diesen Menüpunkt geschlossen 





werden kann. Um herauszufinden, ob das vorderste Fenster zu 
einem Schreibtischprogramm gehört, wird in Zeile 40 die Funk- 
tion Is_DAWindow aufgerufen. Gibt diese Funktion einen Er- 
gebniswert ungleich 0 zurück, so gehört das Fenster zu einem 
Schreibtischprogramm. 


Die neue Funktion Is_DAWindow; 


1: short Is _DAWindow (WindowPtr theWindow) 
2: { 

3: short daRefNunm; 

4 . 

5 


daRefNum = 
((WindowPeek) theWindow) ->windowKkind; 
6 if (daRefNum < 0) 
7: return daRefNum; 
8: else 
9: return 0; 
0 


Is_DAWindow wird von Adjust_Menus und Do_Close aufgeru- 
fen, um herauszufinden, ob ein Fenster zu einem Schreibtisch- 
programm (DA) gehört. 

Is_DAWindow untersucht zu diesem Zweck das windowKind- 
Feld des WindowRecords. Ist dieses Feld kleiner 0, so gehört das 
Fenster zu einem DA, und das Feld windowKind enthält eine 
Referenz-Nummer auf dieses Schreibtischprogramm. Wenn das 
Fenster zu einem Schreibtischprogramm gehört, so wird die 
Referenz-Nummer als Ergebniswert zurückgegeben, damit die 
aufrufende Funktion auf das DA zugreifen kann. 


Die erweiterte Version der Funktion Do_FileMenu: 


1: void Do FileMenu (short menultem) 
2: { 

3 switch (menultem) 

4 { 

5% case iNew: 

6: Do_ New (0); 

7 break; 

8 

9 case iOpen: 


14.2 Neue und 


geänderte Funktionen 





Is_DAWindow unter- 
sucht das Feld 
windowKind des 
WindowRecords, um 
festzustellen, ob das 
Fenster zu einem 
Schreibtischprogramm 
gehört. 
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Do_FileMenu unterstützt 
jetzt die Menüpunkte 
"Neu", "Öffnen..." 
‘Sichern‘, 

‘Sichern unter..." und 
‘Schließen‘, indem die 
entsprechenden 
‚Aktionsroutinen 
aufgerufen werden. 


10: Do_Open (); 
11: break; 

12: 

13: case iClose: 
14: Do_ Close (); 
15% break; 

16: 

17: case iSave: 
18: Do_Save (); 
19: break; 

20: 

21: case iSaveAs: 
22: Do_SaveAs (); 
23: break; 

24: 

25: case iQuit: 
26: Do Quit (0); 
27: break; 

28: } 

29: } 


Die Funktion Do_FileMenu wurde so erweitert, daß sie zusätz- 
lich auf die Auswahl der Menüpunkte "Neu", "Öffnen...", "Si- 
chern", "Sichern unter..." und "Schließen" reagiert, indem die 
entsprechenden Aktionsroutinen aufgerufen werden. 

In Zeile 6 wird auf die Auswahl des Menüpunktes "Neu" reagiert, 
indem die Funktion Do_New aufgerufen wird, um ein neues 
Dokument zu erzeugen. 

Wenn der Benutzer den "Öffnen..."-Menüpunkt auswählt, so wird 
in Zeile 10 die Funktion Do_Open aufgerufen, welche den 
Standard-Öffnen-Dialog erzeugt und ein neues Dokument auf 
der Basis der ausgewählten Datei erzeugt. 

In Zeile 18 wird die Funktion Do_Save aufgerufen, wenn der 
Benutzer den "Sichern"-Menüpunkt ausgewählt hat. Diese 
Funktion kümmert sich um das Abspeichern einer geänderten 
oder neuen Datei. 

In Zeile 22 wird auf die Auswahl des "Sicher unter..."-Menü- 
punktes reagiert, indem die Funktion Do_SaveAs aufgerufen wird. 
Diese Funktion erzeugt den Standard-Sichern-Dialog und ruft 
anschließend die Funktion Save_Document auf, um die Daten in 
die angelegte Datei zu schreiben. 


14.2 Neue und 


geänderte Funktionen 





Die neue Funktion Do_SaveAs: 


1: Boolean Do _SaveAs (void) Do_SaveAs reagiert auf 
2: { die Auswahl des 
3 Boolean documentSaved = false; Menüpunktes 
= N eh ‘Sichern unter...". Diese 
SE Point where; r Re 
6 OSErr er: Funktion präsentiert 
7 DocumentPtr theDocument; dem Benutzer den 
8: WindowPtr theWindow; Standard-Sichern- 
9: Str255 defaultName; Dialog, erzeugt eine 
= SetPt (&where, 100, 100) DR U IL 
ha 1 1 f . . 
12: thewWindow = FrontWindow (); arsehlaRand GaNR.02B 
13: GetWTitle (theWindow, defaultName) ; die Daten des Doku- 
14: SFPutFile (where, "\pSichern unter:", ments in diese Datei 
defaultName, NULL, &reply); gesichert werden. 
15: if (reply.good)16: { 
17: err = FSDelete (reply.fName, 
reply.vRefNum); 
18: err = Create (reply.fName, 
reply.vRefNum, 'XP1U', 'OVAL'); 
19: 
20: theDocument = (DocumentPtr) theWindow; 
21: theDocument->reply = reply; 
22: 
23: Save Document (); 
24: theDocument->hasBeenSaved = true; 
25: SetWTitle (theWindow, reply.fName); 
26: } 
27: return reply.good; 
28: } 


Do_SaveAs fragt in Zeile 12 zunächst mit der Window-Mana- 
ger-Funktion FrontWindow nach dem vordersten Fenster. Die- 
ses Fenster ist gleichzeitig der Verweis auf das Dokument, auf 
welches sich der Menübefehl bezieht. 

Die Funktion Do_SaveAs verwendet in Zeile 14 SFPutFile, um dem 
Benutzer den üblichen Sichern-Dialog zu präsentieren, in welchem 
er einen Dateinamen eingeben und die Position der neuen Datei 
im Dateisystem auswählen kann. Dieser Funktion wird als Default- 
Dateiname der Titel des vordersten Fensters übergeben, welcher 
in Zeile 13 durch die Funktion GetWTitle erfragt wird. 
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Bevor eine neue Datei 
angelegt wird, sollte 
unbedingt dafür gesorgt 
werden, daß keine Datei 
mit gleichem Namen in 
dem selben Directory 
existiert. 


Der Verweis auf die 
verbundene Datei wird 
im Dokument abgelegt. 


Wenn der Benutzer die Datei sichern möchte (reply.good = true), 
so wird dafür gesorgt, daß eine eventuell existierende Datei in 
Zeile 17 gelöscht und eine neue in Zeile 18 angelegt wird. Bei der 
Erzeugung der Datei wird der ungewöhnliche Creator-Type 'XP1U' 
verwendet, um einen Konflikt mit bestehenden Creator-Types 
zu vermeiden (obwohl keine Garantie besteht, daß dieser Creator- 
Type von keiner anderen Applikation verwendet wird). Bei der 
Erstellung einer professionellen Applikation sollte ein Creator- 
Type bei Apple Computer beantragt werden. Als File-Type wird 
hier ein privater File-Type verwendet, was bedeutet, daß die an- 
gelegte Datei von keiner anderen Applikation gelesen werden 
kann. 

In Zeile 20 wird Type-Casting verwendet, um die Variable 
theWindow in einen DocumentPtr zu verwandeln, da im Fol- 
genden auf den Document-struct zugegriffen werden soll. 
Zeile 21 legt die Antworten des Benutzers (Dateiname, Volume- 
Reference-Number etc...) im Document-struct ab, so daß die 
Referenz auf die Datei für ein erneutes Sichern erhalten bleibt. 
In Zeile 23 wird schließlich die Funktion Save_Document auf- 
gerufen, um die Daten des Dokuments in die Datei zu schreiben. 
Zeile 24 sorgt dafür, daß andere Programmteile erkennen, daß 
die Datei bereits gesichert wurde, indem das FlaghasBeenSaved 
auf den Wert true gesetzt wird. 

Nachdem die Datei gespeichert wurde, wird der Titel des Fensters 
in Zeile 25 durch den Aufruf der Window-Manager-Funktion 
SetWTitle dem Dateinamen gleichgesetzt. 

In Zeile 27 wird true oder false zurückgegeben, je nachdem, ob 
der Benutzer die Datei speichern wollte oder nicht. 


Die neue Funktion Save_Document: 


1: void Save Document (void) 

2: { 

3: OSErr err; 

4: DocumentPtr theDocument; 

3: long count; 

6: short fRefNum; 

7 SFReply reply; 

8 

9: theDocument= (DocumentPtr) FrontWindow () ; 
10: reply = theDocument->reply; 


14.2 Neue und 
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11: 


12: count = sizeof (Rect); 

13% err = FSOpen (reply.fName, reply.vRefNum, Save_Document sichert 
&fRefNum); die Dokumentdaten in 

14°: err = FSWrite (fRefNum, &count, 


die zugehörige Datei. 
(Ptr) &theDocument->documentData); 


15: err = FSClose (fRefNum) ; 

16: 

17: err = FlushVol (NULL, reply.vRefNum); 
18: theDocument->hasBeenChanged = false; 
19: } 


Die Funktion Save_Document übernimmt das Abspeichern ei- 

nes Dokuments in eine bereits angelegte Datei. Sie wird von 

Do_SaveAs oder Do_Save aufgerufen. 

Die Funktion verwandelt in Zeile 9 den Ergebniswert von 

FrontWindow mit Hilfe von Type-Casting in einen DocumentP!tr, 

da der Document-struct des vordersten Fensters für die folgen- 

den Zeilen benötigt wird. 

In Zeile 10 wird die lokale Variable reply dem Feld reply aus dem 

Document-struct gleichgesetzt, um in den folgenden Aufrufen 

die Dereferenzierung zu sparen. Dies macht den Quelltext über- 

sichtlicher und beugt Fehlern vor. 

In Zeile 12 wird die lokale Variable count auf die Anzahl der zu Die Dokumentdaten 
schreibenden Bytes gesetzt (Größe der Dokumentdaten = Anzahl bestehen aus dem 
der Bytes, die von einem Rect belegt werden). umschließenden 
Der Aufruf von FSOpen in Zeile 13 öffnet die Datei, die durch Rechteck des Ovals. 
die Felder des reply-structs spezifiziert wird, zum Schreiben. 

In Zeile 14 werden die Daten des Dokuments (das Rect des Ovals) 

mit Hilfe der Funktion FSWrite in die Datei geschrieben. 

Zeile 15 schließt die Datei durch den Aufruf der Funktion FSClose. Nachdem die Datei 
In Zeile 17 wird der Volume-Cache "entleert", so daß die Datei gesichert worden ist, 
auch wirklich auf die Festplatte (und nichtnurin den RAM-Puffer) sollte der Volume-Gache 
geschrieben wird. Dies beugt Datenverlusten bei einem System- 'geflusht" werden. 
absturz vor. 

In Zeile 18 wird das hasBeenChanged-Flag auf false gesetzt, so 

daß der "Sichern"-Menüpunkt deaktiviert wird, solange der Be- 

nutzer die Daten des Dokuments nicht geändert hat. 
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Do_Save reagiert auf die 
Auswahl des "Sichern’- 
Menüpunktes und 
entscheidet, ob der 
Standard-Sichern-Dialog 
erzeugt werden muß, 
oder ob die Datei nur 
aktualisiert werden soll. 


Do_CloseWindow ruft 
Jetzt Do_Close auf, um 
das Dokument zu 
schließen. 


Die neue Funktion Do_Save: 


void Do_Save (void) 
I 
: DocumentPtr theDocument; 


if (theDocument->hasBeenSaved == false) 
Do_SaveAs (); 
else 


1: 
2 
3 
4: 
53 theDocument = (DocumentPtr)FrontWindow () ; 
6 
7 
8 
9 Save_Document (); 

0 


10: } 

Die Funktion Do_Save wird von Do_FileMenu aufgerufen, wenn 
der Benutzer den "Sichern"-Menüpunkt ausgewählt hat. Diese 
Funktion entscheidet, ob der Sichern-Dialog erzeugt werden muß 
oder ob die Datei direkt gesichert werden kann. 

Wenn der Benutzer ein Dokument sichern möchte, welches noch 
nie gesichert worden ist, so sollte der Sichern-Dialog erzeugt 
werden, um dem Benutzer die Möglichkeit zu geben, einen 
Dateinamen einzugeben und die Position der Datei im Datei- 
system zu spezifizieren. Dies geschieht in Zeile 7 durch den Auf- 
ruf der Funktion Do_SaveAs, wenn das hasBeenSaved-Flag des 
Document-Structs auf false steht (Dokument ist noch nie gesichert 
worden). 

Wenn die Datei schon einmal gesichert worden ist, so wird die 
Funktion Save_Document aufgerufen, welche die Daten der Datei 
in die bereits existierende Datei schreibt, ohne den Sichern-Dia- 
log zu erzeugen. 


Die modifizierte Version der Funktion Do_CloseWindow: 


void Do_CloseWindow (WindowPtr theWindow) 


{ 
if (TrackGoAway (theWindow, gEvent.where)) 
Do_Close (); 


Wenn der Benutzer ein Fenster mit Hilfe des Schließfeldes schließen 
will, so ruft Do_CloseWindow jetzt Do_Close auf, um das Do- 
kument zu schließen. Do_Close erzeugt einen Alert, wenn die 


Daten des Dokuments verändert worden sind. In diesem Alert 
kann der Benutzer auswählen, ob er die Daten sichern oder die 
Änderungen verwerfen will. 


Do_Close verwendet für die Erzeugung des Alerts eine 'ALRT'- 
Resource, die in Verbindung mit der entsprechenden 'DITL'- 
Resource das Layout des Alerts definiert: 


(129) { 
418}, 


resource "'ALRT' 
{100, 56, 219, 
129, 


t OK, 


OK, 


visible, 
visible, 
visible, 
visible, 


soundl, 
soundl, 
soundl, 
soundl 


1: 

2 

3 

4 

5: OK, 
6: 

7 OK, 
8: } 
9: }; 


Diese Alert-Resource spezifiziert, daß in jeder Alert-Stufe ein 
Warnton ausgegeben werden soll, und daß der OK-Button (das 
erste Element der 'DITL'-Resource) der Default-Button sein soll. 


N Anderungen von “Ohne Titel” sichern? 





Die korrespondierende 'DITL'-Resource: 


1: resource 'DITL' (129) { 

2 { 

3 {87, 268, 107, 348}, 
4: Button { 

5% enabled, 

6: "Sichern" 

7 }h 

8: {87, 168, 107, 248}, 
9: Button { 

10: enabled, 

11: "Abbrechen" 

12: }r 

13: {87, 12, 107, 108}, 


14.2 Neue und 


geänderte Funktionen 





Die 'ALRT'-Resource 
des "Änderungen 
sichern ?’-Alerts. 


Abb. 14-6 

Do_Close erzeugt einen 
Alert, wenn die Daten 
des Dokuments 
geändert worden sind. 


Die 'DITL'-Resource 
definiert die Dialog- 
elemente des ‘Änderun- 
gen sichern ?’-Alerts. 
Der Sichern-Button ist 
der Default-Button, da er 
in der Dialogelementliste 
an erster Stelle steht. 
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14: Button { 
15% enabled, 
16: j "Nicht Sichern" 
1.71% hy 
18: {10, 72, 76, 344}, 
19: StaticText { 
20: disabled, 
2% "Änderungen von “*0” sichern?" 
22:3 } 
23: } 
24: }; 


Diese 'DITL'-Resource spezifiziert die Dialogelemente des in Abb. 
14-6 dargestellten Alerts. Das statische Textfeld (Zeilen 18 - 22) 
enthält einen Platzhalter (*0), an dessen Stelle mit Hilfe der Dia- 
log-Manager-Funktion ParamText der Name des Fensters einge- 
setzt wird. 


Die neue Funktion Do_Close: 


Do_Close wird aufgeru- 1: Boolean Do_Close () 
fen, wenn der Benutzer 2: { 
ein Dokument schließen A a . ; 5 
2 ; i efine ance 
möchte (Schließfeld 02 5: ee ar 
Fensters oder Menü- 6 
punkt "Schließen‘). 7 Boolean closeDocument = true; 
8: short itemHit, daRefNum; 
9: DocumentPtr theDocument; 
10: WindowPtr thewindow; 
11: Str255 title; 
12: 
Wenn das zu schließen- 13: theWindow = FrontWindow (); 
de Fenster zu einem 14: daRefNum = Is DAWindow (theWindow); 
Schreibtischprogramm nn e daReENum) 
gehört, so wird das DA 17: CloseDeskAcc (daRefNum) ; 
beendet. 18: return true; 
19: } 
20: 
21: theDocument = (DocumentPtr) theWindow; 
22: 
23: if (theDocument->hasBeenChanged) 
24: { 
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25: GetWTitle (theWindow, title); 

26: ParamText (title, "\p", "\p", "\p"); 

27: itemHit = CautionAlert 

(rSaveChangesAlert, NULL); 

28: switch (itemHit) 

29: { 

30: case dSave: 

32: if (theDocument->hasBeenSaved == 
false) 

32: closeDocument = Do_SaveAs (); 

33: else 

34: Save Document (); 

35: break; 

36: 

37: case dCancel: 

38: closeDocument = false; 

39: break; 

40: } 

41: } 

42: 

43: if (closeDocument) 

44: { 

45: CloseWindow (theWindow) ; 

46: theDocument->inUse = false; 

47: gCountDocuments--; 

48: } 

49: return closeDocument; 

50: } 


Do_Close wird aufgerufen, wenn der Benutzer ein Dokument 
bzw. ein Fenster schließen will. Sie wird von Do_CloseWindow 
aufgerufen, wenn der Benutzer in das Schließfeld des Fensters 
klickt, oder von Do_FileMenu, wenn der Benutzer den "Schließen"- 
Menüpunkt auswählt. 

Wenn der Benutzer den "Schließen"-Menüpunkt auswählt, wäh- 
rend ein Schreibtischprogramm im Vordergrund ist, so möchte 
er das Schreibtischprogramm (DA) beenden. Um herauszufinden, 
ob das vorderste Fenster zu einem Schreibtischprogramm gehört, 
wird in Zeile 14 die Funktion Is_DAWindow aufgerufen. Wenn 
der Ergebniswert dieser Funktion ungleich 0 ist, so gehört das 
vorderste Fenster zu einem DA. In diesem Fall wird in Zeile 18 
die Desk-Manager-Funktion CloseDeskAcc aufgerufen, um das 
Schreibtischprogramm zu schließen. Bei dem Aufruf von 


14.2 Neue und 


fetztz tale JccH tal sttelaizie) 





Do_Close erzeugt den 
"Änderungen sichern ?"- 
Alert, wenn die Daten 
des Dokuments 
geändert worden sind, 
und gibt dem Benutzer 
die Möglichkeit, die 
Änderungen zu sichern, 
Zu verwerfen oder die 
‚Aktion abzubrechen. 


Aus Kompatibilitäts- 
gründen zu System 6 + 
Single-Tasking-Finder 
wird die Funktion 
CloseDeskAcc aufgeru- 
fen, wenn das vorderste 
Fenster zu einem 
Schreibtischprogramm 


gehört. 
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Auch im Standard- 
Sichern-Dialog steht 
dem Benutzer die 
Möglichkeit offen, die 
Aktion des Fenster- 
schließens abzubrechen. 


CloseDeskAcc wird die Referenz-Nummer des Schreibtischpro- 
gramms (Ergebniswert von Is_DAWindow) übergeben, um das 
zu schließende Schreibtischprogramm zu spezifizieren. 

Do_Close überprüft in Zeile 23, ob die Daten des Dokuments 
geändert worden sind, indem das hasBeenChanged-Flag des 
Document-structs getestet wird. Ist das Dokument geändert 


. worden, so erzeugt Do_Close einen Alert, in welchem der Benutzer 


auswählen kann, ob er die Änderungen sichern oder verwerfen 
möchte, oderober den Vorgang (des Schließens) abbrechen möchte. 
In Zeile 25 wird zunächst mit Hilfe der Window-Manager-Funk- 
tion GetWTitle der aktuelle Fenstertitel abgefragt, um ihn in Zeile 
26 an die Dialog-Manager-Funktion ParamText zu übergeben. Der 
Fenstertitel wird so anstelle des Platzhalters (*0) im statischen 
Textfeld des Alerts eingesetzt. 

In Zeile 27 wird der Alert mit Hilfe der Dialog-Manager-Funktion 
CautionAlert erzeugt, welche das standardisierte Warn-Icon in 
der linken oberen Ecke des Alerts zeichnet, um den Benutzer 
über eine Gefahrensituation zu informieren. 

Anhand des von CautionAlert zurückgegebenen Wertes (die 
Dialogelementnummer des getroffenen Buttons) entscheidet 
Do_Close, ob der Benutzer das Dokument speichern, die Ände- 
rungen verwerfen oder den Vorgang abbrechen möchte. Hat der 
Benutzer den "Sichern"-Button angeklickt, so wird in Zeile 31 
überprüft, ob das Dokument schon einmal gespeichert worden 
ist, indem das hasBeenSaved-Flag des Document-structs abge- 
fragt wird. Wenn das Dokument noch nie gesichert worden ist, 
so wird die Funktion Do_SaveAs aufgerufen, welche den Stan- 
dard-Sichern-Dialog erzeugt. Die lokale Variable closeDocument 
wird auf den Ergebniswert der Funktion Do_SaveAs gesetzt, so 
daß dem Benutzer auch in dem Sichern-Dialog die Möglichkeit 
zum Abbruch der gesamten Aktion offensteht. Hat er in dem 
Sichern-Dialog auf den "Abbrechen"-Button geklickt, so wird das 
Dokument nicht geschlossen, da closeDocument auf false ge- 
setzt wird. Ist das Dokument bereits gesichert worden, so wird 
die Funktion Save_Document aufgerufen, welche die Daten des 
Dokuments in die zugehörige Datei schreibt. 

Wenn der Benutzer in dem Alert den "Abbrechen"-Button aus- 
gewählt hat, so wird die lokale Variable closeDocument in Zeile 


14.2 Neue und 
geänderte Funktionen 
38 auf false gesetzt, was dazu führt, daß das Dokument weder 


geschlossen noch gesichert wird. 

Wenn der Benutzer den "Nicht Sichern"-Button angeklickt hat, 

so wird das Dokument geschlossen, ohne daß die Änderungen 

gesichert werden, da die lokale Variable closeDocument in Zei- 

le 7 initial auf true gesetzt wurde. 

Soll das Dokument geschlossen werden (der Benutzer hat das Beim Schließen des 
Dokument gesichert oder möchte die Änderungen verwerfen), Fensters wird 

so wird in Zeile 45 das Fenster geschlossen, indem die Window- CloseWindow anstelle 
Manager-Funktion CloseWindow aufgerufen wird. Hier wird _der (bisher verwende- 
CloseWindow anstelle von DisposeWindow verwendet, weilbei ten) Funktion 

der Erzeugung des Fensters durch GetNewWindow kein DisposeWindow 
nonrelocatable-Block angelegt wurde, welchen DisposeWindow aufgerufen, da der 
freigeben würde. CloseWindow gibt nur die weitergehenden WindowRecord nicht 
Datenstrukturen (z.B. die Region-Handles der Zeichenumgebung) miteinem 

frei. nonrelocatable-Block 
In Zeile 46 wird der Document-struct als unbenutzt gekennzeichnet, verwaltet wird. 
indem das inUse-Flag auf false gesetzt wird. Dieser struct steht 

nun wieder bereit, um ein neues Dokument aufzunehmen. 

Zeile 47 zählt die globale Variable gCountDocuments um 1 

herunter, da nun ein Dokument weniger existiert. 

In Zeile 49 wird die lokale Variable closeDocument als Er- 

gebniswert zurückgegeben. Der Ergebniswert der Funktion gibt 

also an, ob das Fenster geschlossen wurde, oder ob die Aktion 

abgebrochen wurde. 


Die erweiterte Version von Do_Quit: 


1: void Do_Quit (void) Do_Quit ruft Do_Close 
2: { für jedes geöffnete 
3: Boolean windowClosed; Dokument auf um dem 
2 Benutzer die Möglichkeit 
5: gQuit = true; . 

6 zu geben, geänderte 

7 while (gCountDocuments > 0) Dokumente zu sichern, 
8: { bevor das Programm 
9% windowClosed = Do_Close (); beendet wird. 

10: if (windowClosed == false) 

11: { 

12: gQuit = false; 
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Wenn der Benutzer in 
dem "Änderungen 
sichern ?'-Alert von 
Do_Close den Abbre- 
chen-Button angeklickt 
hat, wird das Programm 
nicht beendet. 


Do_Open erzeugt den 
Standard-Öffnen-Dialog 
und läßt den Benutzer 
eine Datei auswählen. 


13: break; 
14: } 

1.5# } 

16: } 


Die Funktion Do_Quit wird aufgerufen, wenn der Benutzer den 
Menüpunkt "Beenden" aus dem "Ablage"-Menü auswählt. 

In der neuen Version dieser Funktion werden zunächst die ge- 
öffneten Dokumente geschlossen, bevor die Applikation been- 
det wird. 

In Zeile 7 beginnt die while-Schleife, welche solange läuft, bis 
keine Dokumente mehr geöffnet sind, oder der Benutzer die Be- 
enden-Aktion abgebrochen hat. In Zeile 9 wird die Funktion 
Do_Close aufgerufen, um das vorderste Fenster zu schließen. 
Diese Funktion gibt dem Benutzer die Möglichkeit des Abspei- 
cherns oder des Abbruchs, wenn die Daten des zugehörigen Do- 
kuments verändert worden sind. Wenn der Benutzer die Aktion 
abbrechen möchte (Do_Close hat false zurückgegeben), so wird 
die globale Variable gQuit in Zeile 12 wieder auf false gesetzt 
und anschließend die while-Schleife mit Hilfe des break-Statements 
verlassen. Dies führt dazu, daß keine weiteren Dokumente ge- 
schlossen werden und die Applikation nicht beendet wird. 


Die neue Funktion Do_Open: 


1: void Do_Open (void) 

2:4 

3: SFReply reply; 

4: SFTypeList typelist; 

5: Point where; 

6 OSErr err; 

7 short fRefNum; 

8 long count; 

9: DocumentPtr theDocument; 
10: 
11: SetPt (&where, 100, 100); 
12: typeList[0] = '0OVAL'; 
13: SFGetFile (where, "\pDokument öffnen:", 


NULL, 1, typeList, NULL, sreply); 
14: if (reply.good) 
15: { 
16: theDocument = Do_New (); 


14.2 Neue und 
fetzre tale JaccH tal sttelaizie) 
17: if (theDocument) 


18: { 
19: err = FSOpen (reply.fName, Do_Close erzeugt ein 
reply.vRefNum, &fRefNum); neues Dokument und 
20: count = sizeof (Rect); liest die Daten der 
21: err = FSRead (fRefNum, &count, ausgewählten Datei in 
(Ptr) &theDocument->documentData); . 
22: err = FSClose (fRefNum); das Dokument ein. 
23: SetwTitle ((WindowPtr) theDocument, 
reply.fName); 
24: theDocument->hasBeenSaved = true; 
25: theDocument->reply = reply; 
26: } 
27: } 
28: } 


Do_Open wird von Do_FileMenu aufgerufen, wenn der Benut- 
zer den "Öffnen..."-Menüpunkt aus dem "Ablage"-Menü ausge- 
wählt hat. Diese Funktion läßt den Benutzer mit dem gewohnten 
Öffnen-Dialog eine Datei auswählen, liest die Daten aus dieser 
Datei und erzeugt ein neues Dokument auf der Basis dieser Daten. 
Zunächst erzeugt Do_Open den Standard-Öffnen-Dialog, indem 
in Zeile 13 die Funktion SFGetFile aufgerufen wird. Damit dem 
Benutzer nur die Dateien zur Auswahl gestellt werden, dieSkeleton im Standard-Öffnen- 
auch lesen kann, wird das erste Feld der File-Type-ListetypeList Dialog stehen dem 
auf den File-Type 'OVAL' gesetzt. Beim Aufruf von SFGetFilewird Benutzer nur die Dateien 
weiterhin angegeben, daß nur ein File-Type in der Liste enthal- zur Auswahl, die von 
ten ist; dem Benutzer stehen also nur die Dateien zur Auswahl, Skeleton erzeugt 
die von Skeleton geschrieben worden sind (File-Type ='OVAL'). worden sind. 
Wenn der Benutzer eine Datei ausgewählt hat und auf den 
"Öffnen"-Button geklickt hat (reply.good == true), so wird in Zeile 
16 zunächst ein leeres Dokument erzeugt. Wenn der Speicher- 
platz ausgereicht hat, um ein neues Dokument zu erzeugen 
(theDocument != NULL), so wird die Datei im folgenden Pro- 
grammabschnitt geöffnet und eingelesen. 
In Zeile 19 wird die Datei mit Hilfe der File-Manager-Funktion 
FSOpen geöffnet. Die zu öffnende Datei wird bei diesem Aufruf 
durch die Ergebniswerte von SFGetfFile spezifiziert. 
In Zeile 20 wird die lokale Variable count durch das sizeof- 
Statement auf die Anzahl der Bytes gesetzt, die gelesen werden 
sollen (ein Rect hat 8 Bytes). 
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Do_GraphicsClick 
reagiert auf einen 
Mausklick in den 
Grafikbereich des 
Fensters. Diese Funktion 
stellt fest, ob der 
Benutzer in den inneren 
Bereich des Kreises 
geklickt hat und gibt ihm 
die Möglichkeit, den 
Kreis zu verschieben. 


Die Variable count wird in Zeile 21 zusammen mit der Adresse, 
an der die Daten abgelegt werden sollen, an FSRead übergeben. 
FSRead liest nun 8 Bytes aus der Datei in das documentData-Feld 
des Document-structs. 

In Zeile 22 wird die Datei mit Hilfe von FSClose wieder ge- 
schlossen. 

Zeile 23 sorgt mit einem Aufruf von SetWTitle dafür, daß der 
Fenstertitel den Namen der geöffneten Datei erhält. 

In Zeile 24 wird das hasBeenSaved-Flag des Document-structs 
auf true gesetzt, da ja bereits eine Datei existiert, welche mit 
dem Dokument in Verbindung steht. Wenn der Benutzer den 
"Sichern"-Menüpunkt aus dem "Ablage"-Menü auswählt, so 
werden die Daten gesichert, ohne den Standard-Sichern-Dialog 
zu erzeugen. Die Informationen über die gelesene Datei (Datei- 
name, Position im Dateisystem etc...) werden in Zeile 25 im reply- 
Feld des Document-structs abgelegt. Andere Funktionen (wie z.B. 
Save_Document) können dieses Feld nutzen, um auf die ver- 
bundene Datei zuzugreifen. 


Die erweiterte Funktion Do_GraphicsClick: 


1: void Do_GraphicsClick (WindowPtr theWindow) 
2: { 

3: RgnHandle ovalRgn; 

4: Point locMouse; 

53 DocumentPtr theDocument; 

6: Rect ovalRect; 

7: 

8: theDocument = (DocumentPtr) theWindow; 
9: 
10: Set_DrawingEnv (theWindow); 
11: ovalRect = theDocument->documentData; 


12: ovalRgn = NewRgn (); 
13: OpenRgn (); 


14: FrameOval (&ovalRect); 

15: CloseRgn (ovalRgn); 

16: 

17: locMouse = gEvent .where; 

18: GlobalToLocal {&1locMouse) ; 

19: 

20: if (PtInRgn (locMouse, ovalRgn)) 
21: { 


14.2 Neue und 
fetzrz tale JatccH tal sitelaizig) 
22: ovalRect = Track Oval (ovalRect, 


locMouse) ; 


23% theDocument->documentData = ovalRect; 
24: theDocument->hasBeenChanged = true; 
25: } 

26: DisposeRgn (ovalRgn); 

27: Set _WindowEnv (theWindow); 

28: Recalc_Scrollbars (theWindow) ; 

29: } 


Do_GraphicsClick wird von Do_ContentClick aufgerufen, wenn 

der Benutzer in den Fensterinhalt (die Grafik) klickt. Diese Funktion 

überprüft, ob der Mausklick innerhalb des Kreises liegt, und gibt 

dem Benutzer die Möglichkeit, den Kreis zu verschieben. 

Um festzustellen, ob die Mausklickkoordinaten innerhalb des 

Kreises liegen, wird in Zeile 10 zunächst das Koordinatensystem 

durch den Aufruf der Funktion Set_DrawingEnv an die (even- 

tuell) verschobene Grafik angepaßt. 

In den Zeilen 12 bis 15 wird eine Region erzeugt, welche die Fläche 

des Kreises beschreibt. Diese Region wird später dazu verwendet, 

um festzustellen, ob die Mausklickkoordinaten in dieser Region 

(und damit im Kreis) liegen. 

In Zeile 18 werden die Mausklickkoordinaten (die jain globalen Die globalen 
Koordinaten mit dem Event geliefert werden) auf das Koordina- Mausklickkoordinaten 
tensystem der Grafik umgerechnet, indem die QuickDraw- müssen auf das lokale 
Funktion GlobalToLocal aufgerufen wird. Koordinatensystem des 
Zeile 20 überprüft schließlich, ob die Koordinaten innerhalb des Fensters umgerechnet 
Kreises liegen, indem die QuickDraw-Funktion PtInRgn aufge- werden. 

rufen wird. Diese Funktion liefert den Wert true zurück, wenn 

die Koordinaten innerhalb der übergebenen Region liegen. 

Liegen die Koordinaten innerhalb des Kreises, so wird in Zeile 

22 die neue Funktion Track_Oval aufgerufen, welche den Kreis 

der jeweils aktuellen Mausposition "hinterherzieht". Dieser 

Funktion werden die Ausgangskoordinaten des Kreises, sowie 

die Startkoordinaten des Mausklicks übergeben. Wenn Track_Oval 

zurückkehrt, so gibt sie die neue Position des Kreises als Er- 

gebniswert zurück. 

In Zeile 23 werden die Daten des Dokuments (Position des Kreises) 

aktualisiert, indem das Feld documentData an die veränderte 

Kreisposition angepaßt wird. 
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Da die Daten des Dokuments durch diese Aktion verändert worden 
sind, wird das hasBeenChanged-Flag des Document-structs auf 
true gesetzt. Wenn der Benutzer das Dokument nun schließen 
möchte, so wird er gefragt, ober die Änderungen sichern möchte. 
In Zeile 26 wird dafür gesorgt, daß die alloziierte Region wieder 
freigegeben wird. 

Zeile 27 setzt das Koordinatensystem wieder auf den normalen 
Ursprung zurück, indem Set_WindowEnv aufgerufen wird. 

In Zeile 28 wird Recalc_Scrollbars aufgerufen, damit die Scrollbars 
aktiviert werden, wenn Teile des Kreises durch das Verschieben 
unsichtbar geworden sind. 


Die neue Funktion Track_Oval: 


Track_Oval ist für das 1: Rect Track Oval (Rect startRect, 
Mouse-Tracking Point startMouse) 
zuständig; diese |. 

Funktion gibt dem 3% Point oldMouse, newMouse, diffMouse; 
4: Rect ovalRect; 

Benutzer das Gefühl, 5% 

den Kreis zu verschie- 6: PenMode (patXor); 

ben. Dieses "Feedback" 7: FrameOval (&startRect); 

wird erzeugt, indem der 8: ovalRect = startRect; 

Kreis jeweils an der 9: newMouse = startMouse; 
aktuellen Mausposition a BLDBSe Rus 
i j 1.1: while (Button ()) 
gezeichnet wird. 12: { 
13% GetMouse (&newMouse); 
14 if (!EqualPt (oldMouse, newMouse)) 
15: { 
16: diffMouse = newMouse; 
17: SubPt (startMouse, &diffMouse); 
18: FrameOval (&ovalRect); 
19: 
20: ovalRect = startRect; 
21: OffsetRect (&ovalRect, diffMouse.h, 
diffMouse.v); 
22: if (ovalRect.left < 0) 
23: { 
24: ovalRect.left = 0; 
25: ovalRect.right = 
startRect.right-startRect..left; 

26: } 
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27: 

28: if (ovalRect.top < 0) 

29: { 

30: ovalRect.top = 0; 

31: ovalRect.bottom = 
startRect ..bottom-startRect.top; 

32: } 

33: 

34: FrameOval (&ovalRect); 

35: oldMouse = newMouse; 

36: } 

3%: } 

38: FrameOval (&startRect); 

39: PenNormal (); 

40: return ovalRect; 

al: } 


Die Funktion Track_Oval wird von Do_GraphicsClick aufgeru- 
fen, wenn der Benutzer in den Inhalt des Kreises klickt, um ihm 
die Möglichkeit zu geben, den Kreis zu verschieben. Track_Oval 
übernimmt die Kontrolle und verfolgt die Mausposition, wobei 
der Kreis jeweils an der aktuellen Mausposition neu gezeichnet 
wird, um ein sogenanntes "Feedback" (Rückmeldung) zu erzeu- 
gen. 

Die Funktion verwendet vier lokale Variablen: 

1. Der Point oldMouse enthält die letzte Mausposition. 

2. Der Point newMouse enthält die aktuelle Mausposition. 

3. Der Point diffMouse enthält die Differenz zwischen Start- und 
aktueller Mausposition. 

4. Das Rect ovalRect enthält die aktuelle Position des Kreises. 
In Zeile 6 wird der Zeichen-Modus auf invertierend geschaltet, 
indem die QuickDraw-Funktion PenMode mit patXor aufgeru- 
fen wird. Sämtliche nachfolgenden Zeichenoperationen malen 
jetzt invertierend, was die Implementierung des Mouse-Trackings 
wesentlich vereinfacht. 

In Zeile 7 wird das Oval zunächst gelöscht, indem FrameOval 
aufgerufen wird, damit die nachfolgenden Zeichenoperationen 
keine Ovale stehen lassen. 

Die Zeilen 8 bis 10 setzen die lokalen Variablen auf ihre initialen 
Werte. 


14.2 Neue und 


geänderte Funktionen 
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Wenn der Benutzer die 
Mausposition während 
des Mouse-Trackings 
aus dem Fenster 
"herauszieht', so bleibt 
der Kreis am Fenster- 
rand "kleben". 


die Maustaste losläßt. 

In Zeile 13 wird die aktuelle Mausposition durch den Aufruf der 
Funktion GetMouse abgefragt, um sie in Zeile 14 mit der letzten 
Mausposition zu vergleichen. 

Hatsich die Position geändert (die QuickDraw-Funktion EqualPt 
hat false zurückgegeben), so wird der Kreis in den nachfolgen- 
den Programmzeilen zur neuen Position geschoben. 

Zunächst wird in Zeile 16 bzw. 17 die Differenz zwischen der 
Start- und der aktuellen Mausposition ausgerechnet, indem die 
QuickDraw-Funktion SubPt aufgerufen wird. 

Zeile 18 sorgt dafür, daß der Kreis an der zuletzt gezeichneten 
Stelle gelöscht wird, indem FrameOval für die aktuelle Kreis- 
position aufgerufen wird. 

In den Zeilen 20 bis 32 wird die neue Position des Kreises ausge- 
rechnet. Diese Berechnung gestaltet sich deshalb so komplex, weil 
verhindert werden soll, daß der Benutzer den Kreis in negative 
Koordinatenbereiche verschiebt (zu weit nach links oder nach 
oben). 

Zunächst wird der Kreis auf die Position gebracht, die der aktuellen 
Mausposition entspricht, indem die lokale Variable ovalRect auf 
das Startrechteck gesetzt und danach um die Differenz der Start- 
und aktuellen Mausposition verschoben wird (Zeilen 20 und 21). 
Wenn die neue horizontale Position des Kreises im negativen 
Bereich liegt, so wird die horizontale Position auf 0 gesetzt. 
Das gleiche Kontrollverfahren wird in den Zeilen 28 bis 32 für 
die vertikalen Koordinaten des Kreises wiederholt. 

In Zeile 34 wird der Kreis an der neuen Position gezeichnet und 
die alte Mausposition der neuen gleichgesetzt, so daß erneutes 
Zeichnen erst dann stattfindet, wenn sich die Mausposition 
verändert hat. 

In Zeile 38 wird der alte Kreis endgültig gelöscht, indem FrameOval 
mit den Startkoordinaten aufgerufen wird. 

Zeile 39 gibt den Ergebniswert (die neuen Koordinaten des Kreises) 
zurück. 


14.2 Neue und 


geänderte Funktionen 





Die modifizierte Version von Draw_Graphics: 


1: void Draw Graphics (WindowPtr theWindow) Draw_Graphics 

2: { berücksichtigt jetzt die 
33; DocumentPtr theDocument; variable Position des 
4: Rect ovalRect; 5 

5: Kreises. 

6 theDocument = (DocumentPtr) theWindow; 

7 ovalRect = theDocument->documentData; 

8 FrameOval (&ovalRect); 

9} 


Draw_Graphics zeichnet den Kreis jetzt an der Stelle, an die er 
vom Benutzer verschoben wurde, indem in Zeile 7 die Koordi- 
naten des Kreises aus den Dokumentdaten abgefragt werden. 


Die modifizierte Version von Get_ContentSize: 


1: void Get _ContentSize (WindowPtr theWindow, Get_ContentSize 
short *horiz, berechnet die Größe der 
short *vert) Gesamtgrafik aus der 

ee aktuellen Position des 

3: DocumentPtr theDocument; . 

4: Rect ovalRect; Kreises. 

5: 

6: theDocument = (DocumentPtr) theWindow; 

T: ovalRect = theDocument->documentData; 

8: *horiz = ovalRect.right; 

9: *vert = ovalRect.bottom; 

10: } 


Die neue Version von Get_ContentSize setzt die Höhe bzw. Breite 
der Grafik der rechten bzw. unteren Koordinate des Kreises gleich. 
Auf diese Weise werden die Scrollbars von Recalc_Scrollbars ak- 
tiviert, wenn der Benutzer den Kreis mit der Maus so weit ver- 
schiebt, daß ein Teil unsichtbar wird. Wenn er den Kreis wieder 
zurück schiebt, so werden die Scrollbars wieder deaktiviert. 
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Auf der Grundlage 
dieser 'WIND'-Resource 
werden neue Fenster 
erzeugt. 


Diese 'CNTL'-Resource 
wird bei der Erzeugung 
des vertikalen Scrollbars 
verwendet. 


Diese 'CNTL'-Resource 
dient als Template für 
den horizontalen 
Scrollbar. 


14.3 Quelltext: "Skeleton.r" 


Zum Abschluß dieses Kapitels (und der Serie der Beispiel- 
Programme) wird hier der komplette Quelltext von Skeleton 
aufgelistet. Zunächst wird die Resource-Beschreibungsdatei 
"Skeleton.r" vorgestellt, der eigentliche Quelltext "Skeleton.c" folgt 
anschließend. 


1: /* Typendeklarationen*/ 
23 
3: #include "Types.r" 
4: 
5: /* Window-Template */ 
6: 
7: resource 'WIND' (128) { 
8 {40, 40, 340, 440}, 
9% zoomDocProc, 
10: visible, 
11: GoAway, 
12: 0x0, 
13: "Ohne Titel" 
14: }; 
15; 
16: /* Vertikaler Scrollbar */ 
17: 
18: resource 'CNTL' (128) { 
19: {-1, 385, 286, 401}, 
20: 0, 
21: visible, 
22: 0, 
23: 0, 
24: scrollBarProc, 
25: 0, 
26: ". 
27: }; 
28 
29: /* Horizontaler Scrollbar */ 
30 
31: resource 'CNTL' (129) { 
32: {285, -1, 301, 386}, 
33% 0, 
34: visible, 
358 0, 
36: 0, 


37: scrollBarProc, 

38: 0, 

39: da 

40: }; 

41: 

42: /* Menüleiste */ 

43: 

44: resource 'MBAR' (128) { 

45: { 

46: 128, /*"Apple" 

47: 129, /*"Ablage" 

48: 130 /*"Bearbeiten" */ 

49: } 

50%..% 

51: 

52: /* "Apple"-Menü */ 

53: 

54: resource 'MENU' (128) { 

55: 128, 

56: textMenuProc, 

57: allEnabled, 

58: enabled, 

59: apple, 

60: { 

61: "Über Skeleton..", nolcon, noKey, 
62: noMark, plain, 

63: "-", nolcon, noKey, noMark, plain 
64: } 

65: }; 

66: 

67: /* "Ablage"-Menü */ 

68: 

69: resource 'MENU' (129) { 

70: 129, 

gar textMenuProc, 

72: allEnabled, 

13% enabled, 
‚14: "Ablage", 

1.95% { 

76: "Neu", nolcon, "N", noMark, plain, 
77: "Öffnen..", nolcon, 

78: "_"  nolcon, noKey, noMark, plain, 
19: "Schließen", nolcon,"W", noMark, plain, 
80: "Sichern", nolcon, "S", noMark, plain, 
81: "Sichern unter.."”, nolcon, 


noMark, plain, 


"oO", noMark, plain, 


14.3 Quelltext 


"Skeleton.r" 





Die 'MBAR'-Resource 
enthält die Resoure-IDs 
der 'MENU'-Resources, 
welche in der Menü- 
leiste zusammengefaßt 
sind. 


Diese 'MENU'-Resource 
definiert das "Apple'- 
Menü. Die Namen der 
Schreibtischprogramme 
werden erst zur Laufzeit 
eingetragen. 


Das 'Ablage'-Menü. 
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82: "-", nolcon, noKey, noMark, plain, 
83: "Seitenformat..", nolcon, noKey, noMark, 
plain, 
84: "Drucken..", nolcon, "P", noMark, plain, 
85: "-", nolcon, noKey, noMark, plain, 
86: "Beenden", nolcon, "Q", noMark, plain 
87: } 
88: }; 
89: 
90: /* "Bearbeiten"-Menü */ 
91: 
Das standardisierte 92: resource 'MENU' (130) { 
"Bearbeiten'-Menü. 93: 130, 
94: textMenuProc, 
95: allEnabled, 
96: enabled, 
9: "Bearbeiten", 
98: { 
99: "widerrufen",nolcon, "Z2",noMark,plain, 
100: "-", nolcon, noKey, noMark, plain, 
101: "Ausschneiden", nolcon, "X", noMark, 
plain, 
102: "Kopieren",nolcon, "C",noMark,plain, 
103: "Einsetzen",nolcon, "V",noMark,plain, 
104: "Löschen",nolcon,noKey,noMark,plain, 
105: "-", nolcon, noKey, noMark, plain, 
106: "Zwischenablage", nolcon, noKey, 
107: noMark, plain 
108: } 
109: }7 
110: 
111: /* Smilie-Bild (verkürzt) */ 
112: 
Dieses Picture wird in 113: resource 'PICT' (128) { 
dem "Über Skeleton... - 114: 293, 
Dialog verwendet. +1: {=1, -1, 74, 74}, 
116: $"1101 A000 8201 000A" 
117: S"000A FFFF FFFF 004A" 
118: s"1223 0900 0083 FF" 
119: }; 
120: 
121: /* Dreifache Umrandung (verkürzt) */ 
122: 
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123: 
124: 
125: 
126: 
127: 
128: 
129: 
130: 
131: 
132: 
133: 
134: 
135: 
136: 
137: 
138: 
139: 
140: 
141: 
142: 
143: 
144: 
145: 
146: 
147: 
148: 
149: 
150: 
151# 
152: 
153: 
aus dem Buch\nMacintosh 


resource 'PICT' (129) { 
98, 
{-1, 1; 29, 89}, 
$"1101 A000 8201 000A" 
$5"0003 000B 0010 0010" 
5"0059 00AO 0083 FF" 
}i 


/* Cluster-Rahmen (verkürzt) 


resource 'PICT' (130) { 
39, 
{-1, -1, 56, 164}, 
$"1101 A000 8201 000A" 
5"0083 000B 8201 0900 " 
$"3000 A4AO 0083 FF" 

}; 


/* Über Skeleton-DITL */ 


resource 'DITL' (128) { 
{ 

{135, 287, 155, 367}, 

Button { 
enabled, 
"OK" 

}r 

{10, 74, 76, 316}, 

StaticText { 
disabled, 


"Skeleton.\nEin Beispiel-Programm 
Programmieren in 


C\nCarsten Brinkschulte 1992" 


154: 
1:55: 
156: 
157: 
158: 
159: 
160: 
161: 
162: 
163: 
164: 
165: 
166: 


}r 
{13, 10, 63, 60}, 
Picture { 

disabled, 

128 
}r 
{129, 281, 159, 371}, 
Picture { 

disabled, 

129 
}, 
{106, 87, 124, 212}, 
RadioButton { 


ur 


14.3 Quelltext 


"Skeleton.r" 





Dieses Picture enthält 
die dreifache Um- 
rahmung eines Default- 
Buttons. 


Diese 'PICT'-Resource 
enthält den Cluster- 
Rahmen der Radio- 
Buttons. 


Die 'DITL'-Resource 
enthält die Dialog- 
elemente des "Über 
Skeleton...'-Dialogs. 
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Diese 'DLOG'-Resource 
definiert u.a. die 
Position und Größe des 
Dialogfensters. 


Diese Dialog-Item-List 
('DITL')-Resource 
enthält die Dialog- 

elementliste des 
"Änderungen sichern ?"- 
Alerts. 


enabled, 
"Radio Button #1" 
}r 
{123, 87, 141, 215}, 
RadioButton { 
enabled, 
"Radio Button #2" 
}r 
{93, 76, 148, 225}, 
Picture { 
disabled, 
130 
}r 
{88, 84, 104, 135}, 
StaticText { 
disabled, 
"Cluster " 


} 
}; 


/* Über Skeleton-Dialog */ 


resource 'DLOG' (128) { 
{100, 100, 270, 485}, 
dABoxProc, 
visible, 
noGoAway, 
0x0, 
128, 


}; 
/* Sichern?-DITL */ 


resource 'DITL' (129) { 
{ 

{87, 268, 107, 348}, 

Button { 
enabled, 
"Sichern" 

r% 

{87, 168, 107, 248}, 

Button { 
enabled, 
"Abbrechen" 


213: 
214: 
215: 
216: 
217: 
218: 
219: 
220: 
221: 
222: 
223: 
224: 
225: 
226: 
227: 
228: 
229: 
230: 
231: 
232: 
233: 
234: 
235: 
236: 
237: 
238: 


14.4 


oA PrwhrNnH 


}r 
{87, 12, 107, 108}, 
Button { 
enabled, 
"Nicht Sichern" 
}r 
{10, 72, 76, 344}, 
StaticText { 
disabled, 
"Änderungen von “*0” sichern?" 


} 
} 


/* Sichern?-Alert */ 


resource '"ALRT' (129) { 

{100, 56, 219, 418}, 

129, 

{ 
OK, visible, soundl, 
OK, visible, soundl, 
OK, visible, soundl, 
OK, visible, soundl 


Quelltext: "Skeleton.c" 


: #include <Types.h> 

: #include <Memory.h> 

: #include <QuickDraw.h> 
: #include <Fonts.h> 

: #include <Windows.h> 


#include <Events.h> 
#include <ToolUtils.h> 
#include <Menus.h> 


: #include <Desk.h> 
: #include <OSUtils.h> 
: #include <Dialogs.h> 


14.3 Quelltext 


"Skeleton.c" 





Die 'ALRT'-Resource 
enthält die Alert- 
spezifischen Informatio- 
nen des "Änderungen 
sichern ?"-Alerts. 


Die Einbindung der 
Interface-Dateien der 
benötigten Manager 
bewirkt die Bekanntgabe 
der Datenstrukturen und 
Funktionsdeklarationen 
dieser Manager. 
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15: #define rWindow 128 
16: #define rHScrollbar 128 
Diese Konstanten 17: #define rVScrollbar 129 
dienen dem Zugriff auf 18: #define rMenuBar 128 
die Resource- 19: #define rAboutDialog 128 
20: #define rSaveChangesAlert 129 
Templates. e 
222. 3 ren a2 25 
23: 
Menu-ID-Konstanten 24: #define mApple 128 
beginnen mit 'm“. 25: #define mFile 129 
26: #define mEdit 130 
27: 
28: // ----=--22222222222222272 
29: 
Die Konstanten für die 30: #define iAbout 1 
Menüpunktnummern 31: 
beginnen mit 'j" (item). . en 
34: #define iNew 1 
35: #define iOpen 2 
36: #define iClose 4 
37: #define iSave 5 
38: #define iSaveAs 6 
39: #define iPageSetup 7 
40: #define iPrint 9 
41: #define iQuit 11 
42: 
43: // ----72272222272222222222222n 
44: 
45: #define iUndo 1 
46: #define iCut 3 
47: #define iCopy 4 
48: #define iPaste 5 
49: #define iClear 6 
50: #define iClipBoard 8 
51: 
52: // -----22=2272227222222222 
53: 
54: #define kMaxDocuments 10 
99% 
Saul BEER En ee 
57 
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58: 
59; 
60: 


62: 


64: 
65: 
66: 
67: 
68: 
69: 
70: 
71: 
12:5 
43% 
74: 
752 
76: 
77: 
78: 
79: 
80: 
81: 
82: 
83: 
84: 
85: 
86: 
87: 


88: 
89: 
90: 
91: 
92: 
93: 
94: 
95: 
96: 
97: 
98: 
99: 


struct Document { 


windowRecord theWindow; 

ControlHandle vertScrollbar, 
horizScrollbar; 

Boolean inUse, hasBeenChanged, 
hasBeenSaved; 

SFReply reply; 

Rect documentData; 


}; 


typedef struct Document Document; 
typedef Document *DocumentPtr; 


I I===24422424444444442 4 
Document gDocuments [kMaxDocuments]; 
short gCountDocuments; 
EventRecord gEvent; 

Boolean gQuit, gGotEvent; 

I ESH4444n 4444 


void Draw Graphics (WindowPtr theWindow); 
void Set _WindowEnv (WindowPtr theWindow); 
void Set _DrawingEnv (WindowPtr theWindow); 
DocumentPtr Do_New (void); 


M === 444 
void Get _ContentSize (WindowPtr theWindow, 
short *horiz, 
short *vert) 
{ 
DocumentPtr theDocument; 
Rect ovalRect; 


theDocument = (DocumentPtr) theWindow; 
ovalRect = theDocument->documentData; 
*Xhoriz = ovalRect.right; 
*vert = ovalRect.bottom; 


14.3 Quelltext 


"Skeleton.c" 





Ein Document-struct 
faßt Dokumentdaten 
bzw. das Fenster und 
seine Elemente in einer 
Datenstruktur zusam- 
MEN. 


Forward-Declarations 


Die Funktion 
Get_ContentSize 
berechnet die Größe der 
Grafik in Abhängigkeit 
von der Position des 
Kreises. 
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Recalc_Scrollbars 
überprüft, ob Teile der 
Grafik verdeckt sind, 
weil das Fenster zu klein 
oder die Grafik verscho- 
ben ist. Wenn Teile der 
Grafik verdeckt sind, 
werden die Scrollbars 
aktiviert und die 
maximalen Werte der 
Scrollbars der Anzahl 
der verdeckten Punkte 
gleichgesetzt. 


100: 


101: 
102: 


105: 
106: 
107: 
108: 
109: 


110: 
111: 
112: 


113: 
114: 


115: 
1le: 
11%: 
118: 


119: 
120: 
121: 
122: 


123: 
124: 


125: 
126: 


127: 
128: 
129: 
130: 
131: 


132: 


void Recalc _Scrollbars ( 


{ 


wWindowPtr thewWindow) 


short drawRectH, drawRectV, 
contSizeH, contSizeV, 
invisPoints; 

DocumentPtr theDocument; 


drawRectH= theWindow->portRect..right- 15; 

drawRectV= theWindow->portRect..bottom-15; 

Get _ContentSize (theWindow, &contSizeH, 
&contSizeV); 

theDocument = (DocumentPtr) theWindow; 


invisPoints = GetCtlValue ( 
theDocument->vertScrollbar); 
if (contSizeV - invisPoints > drawRectV) 
invisPoints += contSizeV- invisPoints- 
drawRectV; 


if (invisPoints > 0) 
{ 
HiliteControl ( 
theDocument->vertScrollbar, 0); 
SetCt1lMax (theDocument->vertScrollbar, 
invisPoints); 
} 
else 
HiliteControl ( 
theDocument->vertScrollbar, 255); 


invisPoints = GetCtlValue ( 
theDocument->horizScrollbar); 
if (contSizeH - invisPoints > drawRectH) 
invisPoints += contSizeH - 
invisPoints - drawRectH; 


if (invisPoints > 0) 
{ 
HiliteControl ( 
theDocument->horizScrollbar, 0); 
SetCtlMax (theDocument->horizScrollbar, 
invisPoints); 


133: 
134: 


135: 
136: 
137: 
138: 
139: 


140: 
141: 
142: 
143: 


145: 
146: 
147: 


148: 


149: 
150: 
151: 
152: 
153: 
154: 
155: 
156: 
157: 
158: 
159: 
160: 
161: 
162: 
163: 
164: 
165: 
166: 
167: 
168: 
169: 
170: 
12% 





else 
HiliteControl ( 
theDocument->horizScrollbar, 255); 


void Adjust_Scrollbars ( j 
WwindowPtr theWindow) 
{ 


short newPos, newSize; 
DocumentPtr theDocument; 
ControlHandle horizScrollbar, 
vertScrollBar; 

theDocument = (DocumentPtr) theWindow; 
vertScrollBar = 

theDocument->vertScrollbar; 
horizScrollbar = 


theDocument->horizScrollbar; 


newPos = theWindow->portRect.right - 15; 
newSize = theWindow->portRect..bottom -13; 


HideControl (vertScrollBar); 
MoveControl (vertScrollBar, newPos, - 1); 
SizeControl (vertScrollBar, 16, newSize); 


newPos = theWindow->portRect.bottom - 15; 
newSize = theWindow->portRect.right - 13; 


HideControl (horizScrollbar); 
MoveControl (horizScrollbar, -1, newPos); 
SizeControl (horizScrollbar, newSize,16); 


Recalc Scrollbars (theWindow); 


ShowControl (vertScrollBar); 
ShowControl (horizScrollbar); 


14.3 Quelltext 


"Skeleton.c" 





Adjust_Scrollbars wird 
aufgerufen, wenn die 
Fenstergröße verändert 
worden ist. Diese 
Funktion paßt die 
Position und Größe der 
Scrollbars an die neue 
Fenstergröße an. 
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172: Rect Track Oval ( Rect startRect, 
Point startMouse) 


173: { 
Die Funktion Track_Oval 174: Point oldMouse, newMouse, diffMouse; 
gibt dem Benutzerds 175: Rect ovalRect; 
"Feedback', wenn er den 176: 
i ; 177: PenMode (patXor); 
Kreis verschieben 


178: FrameOval (&startRect); 
möchte. Track_Oval 179:  ovalRect = startRect; 
"verfolgt" die Maus- 180: newMouse = startMouse; 

position und zeichnet 181: oldMouse = startMouse; 


den Kreis jeweilandr 182: while (Button ()) 


Stelle, welcheder 183: { 
aktuellen Mausposition 184: GetMouse (&newMouse); 
185: if (!EqualPt (oldMouse, newMouse)) 
entspricht. 186: { 

187: diffMouse = newMouse; 

188: SubPt (startMouse, &diffMouse); 

189: FrameOval (&ovalRect); 

190: 

191: ovalRect = startRect; 

192: OffsetRect (&ovalRect, diffMouse.h, 
diffMouse.v); 

193: if (ovalRect.left < 0) 

194: { 

195: ovalRect.left = 0; 

196: ovalRect.right = startRect.right - 

startRect .left; 

197: } 

198: 

199: if (ovalRect.top < 0) 

200: { 

201: ovalRect.top = 0; 

202: ovalRect.bottom = 
startRect.bottom- startRect.top; 

203: } 

204: FrameOval (&ovalRect); 

205: oldMouse = newMouse; 

206: } 

207: } 


208: FrameOval (&startRect); 
209: PenNormal (); 


210: return ovalRect; 

211: } 

212: 

213: // ------------------------- 
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214: 
215: void Do_GraphicsClick (WindowPtr theWindow) 
216: { 


217: RqanHandle ovalRgn; 
218: Point locMouse; 
219: DocumentPtr theDocument; 
220: Rect ovalRect; 
221: 


222: theDocument = (DocumentPtr) theWindow; 
223: 

224: Set_DrawingEnv (theWindow); 

225: ovalRect = theDocument->documentData; 
226: ovalRgn = NewRgn (); 

227: OpenRgn (); 

228: FrameOval (&ovalRect); 

229: CloseRgn (ovalRgn); 

230: 

231: 1locMouse = gEvent .where; 

232: GlobalToLocal (&1locMouse); 

233: 

234: if (PtInRgn (locMouse, ovalRgn)) 

235: { 


236: ovalRect = Track _Oval (ovalRect, 
locMouse); 

237: theDocument->documentData = ovalRect; 

238: theDocument->hasBeenChanged = true; 

239: } 


240: DisposeRgn (ovalRgn); 
241: Set_WindowEnv (theWindow); 
242: Recalc_Scrollbars (theWindow); 


243: } 

244: 

Zu: A RZEH2S HH ers ss HE 
246: 


247: void Scroll Graphics ( 
WindowPtr theWindow, 


short amountH, 
short amountV) 
248: { 
249: Rect rect2Scroll; 
250: RgnHandle updateRgn; 
251: 


252: Set_DrawingEnv (theWindow); 

253: rect2Scroll = theWindow->portRect; 
254: rect2Scrolli.bottom -= 15; 

255: rect2Scroll.right -= 15; 


14.3 Quelltext 


"Skeleton.c" 





Do_GraphicsGlick wird 
aufgerufen, wenn der 
Benutzer in den 
Grafikbereich des 
Fensters klickt. Diese 
Funktion überprüft, ob 
der Mausklick im 
inneren Bereich des 
Kreises liegt und sorgt 
dafür, daß der Benutzer 
den Kreis verschieben 
kann. 


Scroll_Graphics 
übernimmt den 
"sichtbaren" Teil des 
Scrollens; diese 
Funktion verschiebt die 
Grafik und sorgt dafür, 
daß freigelegte Bereiche 
neu gezeichnet werden. 
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256: updateRgn = NewRgn (); 

257: ScrollRect (&rect2Scroll, amountH, 
amountV, updateRgn); 

258: SetClip (updateRgn); 

259: Draw Graphics (theWindow); 

260: Set_WindowEnv (theWindow); 

261: DisposeRgn (updateRgn); 


262: } 

263: 

264: // ----------------------------- 
265: 

Scroll_Scrollbar setzt 266: short Scroll Scrollbar ( 
den Wert des Scrollbars ControlHandle theControl, 
(die Position des Bea short amount) 
mumbe) Dee 268: short value, maxValue; 


Funktion hat gleichzeitig „69: 


eine Kontro- 270: value = GetCtlValue (theControl); 
funktionalität; sie 271: maxValue = GetCtlMax (theControl); 


überprüft, obundum 2172: 
273: if (value + amount > maxValue) 


wieviele Punkte in die 
ni : 274: amount = maxValue - value; 
gewünschte Richtung 275: 
gescrollt werden Kann. 276: if (value + amount < 0) 
277: amount = -value; 
278: 
279: SetCt1lValue (theControl, amount + value); 
280: 
281: return amount; 
282: } 
283: 
284: // -------2222222222222 
285: 
Do_Scroll übernimmt 286: void Do Scroll (WindowPtr theWindow, 
die Koordination des short amountH, 
Scrollens; diese short amount V) 
287: { 


Funktion sorgt dafür, 288: DocumentPtr theDocument; 
daß die Position der 289: 
Scrollbar-Thumbs 290: theDocument = (DocumentPtr) theWindow; 
aktualisiert und die 291: 
Grafik gescrollt wird. 292: amountH = Scroll_Scrollbar ( 
theDocument->horizScrollbar, amountH); 
293: amountV = Scroll_Scrollbar ( 
theDocument->vertScrollbar, amountV); 
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Scroll Graphics (theWindow, -amountH, 
-amountV); 


ne 
: pascal void Scroll_Proc ( 
ControlHandle theControl, 
short part) 


short amount = 0; 

WindowPtr theWindow; 

DocumentPtr theDocument; 

theWindow = (**theControl) .contrlOwner; 
theDocument = (DocumentPtr) theWindow; 


switch (part) 
{ 
case inPageUp: 
amount = 
- (theWindow->portRect..bottom- 20); 
break; 


case inPageDown: 


amount=theWindow->portRect .bottom-20; 


break; 


case inUpButton: 
amount = -20; 
break; 


case inDownButton: 
amount = 20; 
break; 


if (theControl == 
theDocument->vertScrollbar) 
Do_Scroll (theWindow, 0, amount); 
else 
Do_Scroll (theWindow, amount, 0); 


14.3 Quelltext 


"Skeleton.c" 





Scroll_Proc ist eine Call- 
Back-Routine, die von 
TrackControl aufgerufen 
wird, solange der 
Benutzer z.B. auf den 
"Pfeil nach oben" drückt. 
Scrollproc untersucht, 
in welchen Teil des 
Scrollbars geklickt 
wurde und sorgt dafür, 
daß die Grafik gescrollt 
wird. 
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Do_ContentGlick 
reagiert auf einen Klick 
in den inneren Bereich 
des Fensters. Diese 
Funktion überprüft, in 
welchem Bereich der 
Mausklick liegt 
(Scrollbars oder Grafik) 
und reagiert entspre- 
chend. 

Wenn der Benutzer in 
die Grafik geklickt hat, 
wird ihm die Möglichkeit 
gegeben, den Kreis zu 
verschieben. Hat er die 
Scrollbars angeklickt, so 
sorgt Do_ContentClick 
dafür, daß die Grafik 
verschoben wird. 
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{ 


: void Do_ContentClick (WindowPtr theWindow) 


short part, oldValue, newValue; 
Point locMouse; 

ControlHandle theControl; 

DocumentPtr theDocument; 


if (theWindow != FrontWindow ()) 
{ 
SelectWindow (theWindow) ; 
return; 


} 


SetPort (theWindow) ; 

theDocument = (DocumentPtr) theWindow; 

locMouse = gEvent .where; 

GlobalToLocal (&locMouse); 

part = FindControl (locMouse, theWindow, 
&theControl); 


switch (part) 
{ 
case 0: 
Do_GraphicsClick (theWindow); 
break; 


case inThumb: 
oldValue = GetCtlValue (theControl); 
TrackControl (theControl, locMouse, 
NULL); 
newValue = GetCtlValue (theControl); 
if (oldValue != newValue) 
{ 
if (theControl == 
theDocument->vertScrollbar) 
Scroll Graphics (theWwindow, 0, 
oldValue - newValue); 
else 
Scroll Graphics (theWindow, 
oldValue - newValue, 0); 
Recalc_Scrollbars (theWindow); 
} 
break; 


default: 
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377: 
378: 
379: 
380: 
381: 
382: 
383: 
384: 
385: 
386: 
387: 
388: 
389: 
390: 


391: 
392: 
393: 
394: 
395: 


396: 
397: 
398: 
399: 


400: 
401: 
402: 
403: 
404: 
405: 
406: 
407: 
408: 
409: 
410: 
411: 
412: 
413: 
414: 
415: 
416: 


TrackControl (theControl, locMouse, 

(ProcPtr) &Scroll_ Proc); 
Recalc_Scrollbars (theWindow); 
break; 


void Do DragWindow (WindowPtr theWindow) 
{ 
if (theWwindow != FrontWindow ()) 
SelectWindow (theWindow) ; 


SetPort (theWindow) ; 
DragWindow (theWindow, gEvent.where, 
&qd.screenBits.bounds) ; 


M ÄSeasun 444 
void Do_ZoomWindow ( 

WwindowPtr theWindow, 

short partCode) 


SetPort (theWindow) ; 

EraseRect (&theWindow->portRect); 

if (TrackBox (thewindow, gEvent.where, 
partCode)) 

{ 


Zoomwindow (theWindow, partCode, true); 


Adjust_Scrollbars (theWindow); 
} 


void Do_GrowWindow (WindowPtr theWindow) 
{ 


long newSize; 
short newWidth, newHeight; 
Rect minMaxSize; 


SetPort (theWindow) ; 


minMaxSize.top = 80; 


14.3 Quelltext 


"Skeleton.c" 





Do_DragWindow 
ermöglicht es dem 
Benutzer, die Grafik zu 
verschieben. 


Do_ZoomWindow 
reagiert auf einen 
Mausklick in die Zoom- 
Box des Fensters. 


Do_GrowWindow 
erlaubt es dem 
Benutzer, das Fenster zu 
vergrößern. 
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417: minMaxSize.left = 160; 

418: minMaxSize.right = 
qd.screenBits.bounds.right; 

419: minMaxSize.bottom = 
qd.screenBits.bounds.bottom; 


421: newSize = GrowWindow (theWindow, 
gEvent.where, &minMaxSize); 
422: if (newSize != 0) 


423: { 

424: newwidth = LoWord (newSize); 

425: newHeight = HiWord (newSize); 

4271: Sizewindow (theWindow, newWidth, 
newHeight, true); 

428: Adjust_Scrollbars (theWindow); 

429: InvalRect (&theWindow->portRect); 

430: } 

431: } 

432: 

BB kl Er ne Zar a 

434: 


Save_Document 435: void Save Document (void) 
aktualisiert die Datei, 436: { 


welche mitdem 23’: OSErr SERr 
438: DocumentPtr theDocument; 
aktuellen Dokument 
439: long count; 
(dem vorderen Fenster) 240. Shore fRefNun; 
verbunden ist. 441: SFReply reply; 
442: 


443: theDocument= (DocumentPtr)FrontWindow (); 
444: reply = theDocument->reply; 


445: 
446: count = sizeof (Rect); 
441: err = FSOpen (reply.fName, reply.vRefNum, 


&fRefNum) ; 
448: err = FSWrite (fRefNum, &count, 

(Ptr) &theDocument->documentData) ; 
449: err = FSClose (fRefNum); 


451: err = FlushVol (NULL, reply.vRefNum) ; 
452: theDocument->hasBeenChanged = false; 


453: } 

454: 

ISSN Fressen nF FEnsssse ns 
456: 
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short Is DAWindow (WindowPtr theWindow) 


{ 


ı Boolean Do _SaveAs (void) 


Boolean 

SFReply reply; 

Point where; 

OSErr err; 
DocumentPtr theDocument; 
windowPtr theWindow; 
Str255 defaultName; 


SetPt (&where, 100, 100); 
theWindow = FrontWindow (); 


GetWTitle (theWindow, defaultNane); 
SFPutFile (where, "\pSichern unter:", 
defaultName, NULL, &reply); 


if (reply.good) 
{ 


err = FSDelete (reply.fName, 


reply.vRefNum); 
err = Create (reply.fName, 


reply.vRefNum, 'XP1U', 


theDocument = (DocumentPtr) theWindow; 
theDocument->reply = reply; 


Save Document (); 


theDocument->hasBeenSaved = true; 
SetWTitle (theWindow, reply.fName); 


} 


return reply.good; 


short daRefNum; 


daRefNum = 


((windowPeek) theWindow) ->windowKind; 


if (daRefNum < 0) 
return daRefNum; 
else 
return (0; 


documentSaved = false; 


14.3 Quelltext 


"Skeleton.c" 





Do_SaveAs erzeugt den 
Standard-Sichern- 
Dialog, in welchem der 
Benutzer einen Datei- 
namen eingeben bzw. 
die Position der Datei im 
Dateisystem festlegen 
kann. Diese Funktion 
erzeugt eine neue Datei 
und sorgt anschließend 
dafür, daß die Daten des 
Dokuments in dieser 
Datei gesichert werden. 


Is_DAWindow über- 
prüft, ob ein Fenster zu 
einem Schreibtischpro- 
gramm gehört. 
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Do_Close wird aufgeru- 501: Boolean Do_ Close (void) 
fen, wenn der Benutzer >02: { 


das aktuelle (vordere) >02: tde Ei dSave 1 
Fansher.schliaßen 504: #define dCancel 2 
R EN 505: #define dDontSave 3 
möchte. Sind die Daten 506: 
des zugehörigen 507: Boolean closeDocument = true; 
Dokuments verändert 508: short itemHit, 
worden, dannerzeugt >09: daRefNum; 
die Funktion einen Alert. 510: DocumentPtr theDocument; 
in wecken der Bentber 51l: WwWindowPtr theWindow; 
512: Str255 title; 


entscheiden kann, ob er 513: 
die Änderungen sichern, 514: theWindow = FrontWindow (); 
verwerfen oderde 515: daRefNum = Is DAWindow (theWindow); 
Aktion abbrechen 516: if (daRefNum) 


möchte, >17: { 
518: CloseDeskAcc (daRefNum) ; 
519: return true; 
520: } 
521 
522: theDocument = (DocumentPtr) theWindow; 
523 
524: if (theDocument->hasBeenChanged) 
525: { 
526: GetWTitle (theWindow, title); 
527: ParamText (title, "\p", "\p", "\p"); 
528: itemHit = CautionAlert 
(rSaveChangesAlert, NULL); 
529: switch (itemHit) 
530: { 
531: case dSave: 
532: if (theDocument->hasBeenSaved == 
false) 
533: closeDocument = Do_SaveAs (); 
534: else 
5353: Save _Document (); 
536: break; 
537: 
538: case dCancel: 
539: closeDocument = false; 
540: break; 
541: } 
542: } 
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if (closeDocument) 


{ 
CloseWindow (theWindow) ; 


theDocument->inUse = false; 


gCountDocuments--; 
} 


return closeDocument; 


: void Do CloseWindow (WindowPtr theWindow) 


{ 


if (TrackGoAway (theWindow,gEvent.where)) 


Do_Close (); 


KESSSSESSS SE HE 28222 ES 
: void Set_ItemVal ( DialogPtr 
short 
short 
{ 
short itemType; 
Handle item; 
Rect box; 


GetDItem (theDialog, itemNo, &itemType, 


&item, &box); 


SetCtlValue ((ControlHandle) item, value); 


: void Do_About (void) 


{ 


#define dOoK 1 
#define dRadiol 5 
#define dRadio2 6 
short itemHit; 


DialogPtr theDialog; 


theDialog = GetNewDialog (rAboutDialog, 


NULL, (WindowPtr) -1); 


14.3 Quelltext 
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Do_CloseWindow 
reagiert auf einen 
Mausklick in die Glose- 
Box des Fensters. 


Set_ltemVal ist eine 
Utility-Funktion, mit 
deren Hilfe der Wert 
eines Dialogelements 
(Controls) verändert 
werden kann. 


Do_About wird 
aufgerufen, wenn der 
Benutzer den "Über 
Skeleton. ..'-Menüpunkt 
aus dem 'Apple’-Menü 
auswählt. 
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585: Set_ItemVal (theDialog, dRadiol, 1); 
586: do 
587: { 
Do_About erzeugt einen 588: ModalDialog (NULL, &itemHit); 
modalen Dialog und 589: switch (itemHit) 
reagiert auf Mausklick, >>: { 
bis der Benutzer den eh 
ö 592: Set ItemVal (theDialog, Radio2,0); 
OK-Button anklickt. 593: Set _Itemval (theDialog,dRadiol,1); 
594: break; 
595: 
596: case dRadio2: 
597: Set_ItemVal (theDialog, dRadiol,0); 
598: Set _ItemVal (theDialog,dRadio2,1); 
599: break; 
600: } 
601: } 


602: while (itemHit != dOK); 
603: DisposeDialog (theDialog); 


604: } 

605: 

606: // ---------2-2222 
607: 


Do_AppleMenu reagiert 608: void Do_AppleMenu (short menultem) 
auf die Auswahleines 609: { 


Menüpunktes aus dem 610: short daRefNum; 
z e er 611: Str255 daName; 
Apple’-Menü, indem Es 


entweder der Über «13: switch (menultem) 
Skeleton. ..'-Dialog 614: { 


erzeugt oder das 615: case iAbout: 
ausgewählte Schrei- 616: Do_About (); 

tischprogramm 617: break; 

gestartet wird. 
619: default: 
620: GetItem (GetMHandle (mApple), 

menultem, daName); 

621: daRefNum = OpenDeskAcc (daName) ; 
622: break; 
623: } 
624: } 
625: 
626: // -----=--7---=------- 
627: 
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628: 
629: 
630: 
631: 
632: 
633: 
634: 
635: 
636: 
637: 
638: 
639: 
640: 


641: 
642: 
643: 
644: 
645: 
646: 


647: 
648: 


649: 
650: 


void Do_Open (void) 
{ 


SFReply reply; 
SFTypeList typeList; 
Point where; 

OSErr err; 

short fRefNum; 
long count; 
DocumentPtr theDocument; 


SetPt (&where, 100, 100); 
typeList[0] = 'OVAL'; 
SFGetFile (where, "\pDokument öffnen:", 
NULL, 1, typeList, NULL, &reply); 
if (reply.good) 
{ 
theDocument = Do_New (); 
if (theDocument) 
{ 
err = FSOpen (reply.fName, 
reply.vRefNum, &fRefNum); 
count = sizeof (Rect); 
err = FSRead (fRefNum, &count, 


(Ptr) &theDocument->documentData); 


err = FSClose (fRefNum) ; 


SetWTitle ((WindowPtr) theDocument, 


reply.fName); 
theDocument->hasBeenSaved = true; 
theDocument->reply = reply; 


: void Do_Quit (void) 


{ 


Boolean windowClosed; 


gQuit = true; 
while (gCountDocuments > 0) 


{ 


windowClosed = Do Close (); 


14.3 Quelltext 
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Do_Open wird aufgeru- 
fen, wenn der Benutzer 
den Menüpunkt 
"Öffnen..." aus dem 
"Ablage'-Menü ausge- 
wählt hat. Diese 
Funktion erzeugt den 
Standard-Öffnen-Dialog, 
legt ein neues Doku- 
ment an und liest die 
Daten der ausgewählten 
Datei ein. 


Do_Quit reagiert auf die 
Auswahl des "Beenden’- 
Menüpunktes, indem 

alle noch geöffneten 

Fenster geschlossen 

werden und das 
Terminationskriterium 
gesetzt wird. 375 
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Do_Save reagiert auf die 
Auswahl des 'Sichern'- 
Menüpunktes, indem 
überprüft wird, ob das 
Dokument schon einmal 
gesichert wurde und 
entsprechend verzweigt 
wird. 


Do_FileMenu koordiniert 
die Reaktion auf die 
Auswahl eines Menü- 
punktes aus dem 
"Ablage'-Menü, 


if (windowClosed == false) 
{ 

gQuit = false; 

break; 


: void Do_Save (void) 


{ 


DocumentPtr theDocument; 


theDocument= (DocumentPtr)FrontWindow (); 
if (theDocument->hasBeenSaved == false) 
Do _ SaveAs (); 
else 
Save Document (); 


: void Do FileMenu (short menultem) 


{ 
switch (menultem) 
{ 
case iNew: 
Do_New (); 
break; 


case iOpen: 
Do_Open (); 
break; 


case iClose: 
Do_Close (); 
break; 


case iSave: 
Do_ Save (); 
break; 


case iSaveAs: 
Do_SaveAs (); 
break; 


{ 


case iQuit: 
Do Quit 0; 
break; 


: void Do MenuCommand (long choice) 


short menulD, menultenm; 


menulID = HiWord (choice); 
menultem = LoWord (choice); 


switch (menulD) 


{ 


} 


case mApple: 
Do _AppleMenu (menultem); 
break; 


case mFile: 
Do_FileMenu (menultem); 
break; 


case mEdit: 
SystemEdit (menultem -1); 
break; 


HiliteMenu (0); 


void Adjust_Menus (void) 


{ 


MenuHandle theMenu; 
WindowPtr theWindow; 
DocumentPtr theDocument; 


theMenu = GetMHandle (mFile); 
if (gCountDocuments < kMaxDocuments) 
{ 
EnableItem (theMenu, iNew); 
EnableItem (theMenu, iOpen); 


14.3 Quelltext 
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Do_MenuGommand 
wird aufgerufen, wenn 
der Benutzer einen 
Menüpunkt ausgewählt 
hat. Anhängig vom 
Menü, zu dem der 
ausgewählte Menüpunkt 
gehört, werden die 
entsprechenden 
Behandlungsroutinen 
aufgerufen. 


Adjust_Menus wird 
aufgerufen, bevor der 
Benutzer einen Menü- 
punkt auswählen kann. 
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Adjust_Menus sorgt 
dafür, daß dem Benutzer 
nur die Menüpunkte zur 
Verfügung stehen, die in 
der aktuellen 
Programmsituation 
verwendet werden 
können. 


762: 
763: 
764: 
765: 
766: 
767: 
768: 
769: 
770: 
771: 
772: 
773: 
774: 
775: 
776: 


7771: 
778: 
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780: 
781: 
782: 
783: 
784: 
785: 
786: 
787: 
788: 
789: 
790: 
791: 
792: 
793: 
7194: 
795: 
796: 
797: 
798: 
799: 
800: 
801: 
802: 
803: 
804: 
805: 


} 
else 
{ 
DisableIltem (theMenu, iNew); 
DisableItem (theMenu, iOpen); 
} 


if (gCountDocuments > 0) 

{ 
Enableltem (theMenu, iSaveAs); 
Enableltem (theMenu, iClose); 


theWindow = FrontWindow (); 
theDocument = (DocumentPtr)theWindow; 
if (theDocument->hasBeenChanged | | 
(!theDocument->hasBeenChanged && 
!theDocument->hasBeenSaved) ) 
EnableItem (theMenu, iSave); 
else 
DisableItem (theMenu, iSave); 
} 
else 
{ 
DisableItem (theMenu, iSave); 
DisableItem (theMenu, iSaveAs); 
DisableItem (theMenu, iClose); 
} 


if (Is DAWindow (FrontWindow ())) 

{ 
DisableItem (theMenu, iNew); 
DisableItem (theMenu, iOpen); 
Enableltem (theMenu, iClose); 
DisableItem (theMenu, iSave); 
DisableItem (theMenu, iSaveAs); 
DisableItem (theMenu, iSaveAs); 


void Do_MouseDown (void) 


{ 


short part; 
WwindowPtr thewindow; 


part = FindWindow (gEvent..where, 
&thewWindow); 

switch (part) 

{ 

case inSysWindow: 
SystemClick (&gEvent, theWindow); 
break; 


case inContent: 
Do_ContentClick (theWindow); 
break; 


case inDrag: 
Do_DragWindow (theWindow); 
break; 


case inZoomIn: 

case inZoomOut: 
Do_ZoomWindow (theWindow, part); 
break; 


case inGrow: 
Do_GrowWindow (theWindow); 
break; 


case inGoAway: 
Do_CloseWindow (theWindow) ; 
break; 


case inMenuBar: 
Adjust_Menus (); 
Do _MenuCommand ( 
MenuSelect (gEvent.where)); 
break; 


void Do_KeyDown (void) 


{ 
char key; 


if (gEvent.modifiers & cmdKey) 


{ 
key = gEvent.message & charCodeMask; 


14.3 Quelltext 
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Do_MouseDown wird 
aufgerufen, wenn das 
Programm einen 
MouseDown-Event 
erhält, und koordiniert 
die Reaktion auf diese 
Art von Event. 


Do_KeyDown reagiert 
auf einen KeyDown- 
Event und unterstützt 
Menükurzbefehle. 
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850: Adjust_Menus (); 

851: Do _MenuCommand (MenuKey (key)); 
852: } 

853: } 


Draw_Graphics ist für 857: void Draw Graphics (WindowPtr theWindow) 
das Zeichnen derGrafik 8>8: { 


verantwortlich. Diese 859: DocumentPtr theDocument; 
; . 860: Rect ovalRect; 
Funktion wird aufgeru- 861: 


fen, wenn das Pro- 862: 


theDocument = (DocumentPtr) theWindow; 
gramm einen Update- 863: ovalRect = theDocument->documentData; 
Event erhält. 864: FrameOval (&ovalRect); 
865: } 
866: 
ONE a u EEE EEE 
868: 
Set_DrawingEnv setzt 869: void Set _DrawingEnv ( 
den Koordinatensystem- Windowptr theWindow) 
ursprung so, daßermit 879%: 1 
871: Rect drawableRect; 
der aktuellen ; 
BEER 872: Point origin; 
Scrollposition überein- 873: DocumentPtr theDocument; 
stimmt. Weiterhin sorgt 874: 
diese Funktion dafür, 875: theDocument = (DocumentPtr) theWindow; 
daß die Clipping-Region 876: SetPort (theWindow); 
so gesetztist, daßdie 87°: no 
für die Serollbars 878: origin.h = GetCtlValue ( 


theDocument->horizScrollbar); 


reservierten Bereiche 879: origin.v = GetCtlValue ( 


geschützt sind. theDocument->vertScrollbar); 
880: SetOrigin (origin.h, origin.v); 
881: 
882: drawableRect = theWindow->portRect; 
883: drawableRect.right -= 15; 
884: drawableRect.bottom -= 15; 
885: ClipRect (&drawableRect); 
886: |} 
887: 
BBBE A 
889: 
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928: 
929: 
930: 
931: 
932: 


933: 


void Set WindowEnv (WindowPtr theWindow) 
{ 

SetPort (theWindow) ; 

SetOrigin (0, 0); 

ClipRect (&theWindow->portRect); 


void Do_ Update (void) 
{ 

WindowPtr thewWwindow; 
thewindow = (WindowPtr) qEvent .message; 
Set _WindowEnv (theWindow); 
BeginUpdate (theWindow); 


DrawGrowlIcon (theWindow) ; 
DrawControls (theWindow) ; 


Set_DrawingEnv (theWindow); 
EraseRect (&thewWindow->portRect); 
Draw Graphics (theWindow); 
Set_WindowEnv (theWindow); 


EndUpdate (theWindow); 


void Do Activate (void) 
{ 
WindowPtr 
DocumentPtr 


theWindow; 
theDocument; 


thewindow = (WindowPtr) gEvent..message; 
theDocument = (DocumentPtr) theWindow; 
SetPort (theWindow) ; 


if (gEvent.modifiers & activeFlag) 
{ 
DrawGrowIcon (theWindow) ; 
ShowControl ( 
theDocument->vertScrollbar); 
ShowControl ( 
theDocument->horizScrollbar); 
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Set_WindowEnv setzt 
den Koordinatensystem- 
ursprung bzw. die 
Clipping-Region auf den 
"Normalzustand". 


Do_Update reagiert auf 
einen Update-Event, 
indem die Fenster- 
elemente und die Grafik 
neugezeichnet werden. 


Do_Activate wird 
aufgerufen, wenn das 
Programm einen 
Activate-Event erhält. 
Wird das Fenster 
aktiviert, so werden die 
Scrollbars sichtbar 
gemacht. Wird das 
Fenster deaktiviert, 
werden die Scrollbars 
versteckt. 
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Do_Event ist die 
"Schaltzentrale" der 
Eventverwaltung. Hier 
wird anhand des Event- 
Typs entschieden, 
welche Event-Behand- 
lungsroutine aufgerufen 
wird. 


Init_ToolBox übernimmt 
die Initialisierung der 
benötigten Manager. 


971: 
972: 
973: 
974: 
975: 


SetCursor (&qd.arrow); 
} 
else 
{ 
HideControl ( 
theDocument->vertScrollbar); 
HideControl ( 
theDocument->horizScrollbar); 
DrawGrowIcon (theWindow) ; 


void Do Event (void) 
{ 
switch (gEvent.what) 
{ 
case mouseDown: 
Do_MouseDown (); 
break; 


case keyDown: 

case autokey: 
Do_KeyDown (); 
break; 


case updateEvt: 
Do Update (); 
break; 


case activateEvt: 
Do Activate (); 
break; 


void Init _ToolBox (void) 

{ 
InitGraf ((Ptr) &qd.thePort); 
InitFonts (); 
InitWindows (); 


976: 
97T: 
978: 
979: 
980: 
981: 
982: 
983: 
984: 
985: 
986: 
987: 
988: 
989: 
990: 
991: 
992: 
993: 
994: 
995: 
996: 
997: 
998: 
999: 


1000: 
1001: 
1002: 
1003: 
1004: 
1005: 


1006: 
1007: 


1008: 


1009: 
1010: 
1011: 
1012: 


1013: 
1014: 


InitMenus (); 
TEInit (); 
InitDialogs (NULL); 


void Make Menus (void) 


{ 


Handle menußBar; 


menuBar = GetNewMBar (rMenußBar); 
SetMenuBar (menußBar); 
DisposHandle (menuBar); 


AddResMenu (GetMHandle (mApple), 'DRVR'); 


DrawMenuBar (); 


DocumentPtr Do_New (void) 
{ 
short i=0; 
WindowPtr theWindow; 
a 
for (i = 0; i < kMaxDocuments; i++) 
{ 
if (gDocuments[i].inUse == false) 


{ 


theWindow = GetNewWindow (rWindow, 
(WindowPtr) -1); 


&gDocuments[i], 
SetPort (theWindow) ; 
gDocuments[i].vertScrollbar = 

GetNewControl (rVScrollbar, 

thewindow) ; 
gDocuments[i].horizScrollbar = 

GetNewControl (rHScrollbar, 

thewWindow) ; 
gDocuments[i].inUse = true; 


gDocuments[i] ..hasBeenChanged=false; 
gDocuments[i].hasBeenSaved= false; 


SetRect ( 
&gDocuments[i].documentData, 
10, 10, 210, 210); 

gCountDocuments+t+; 

return &gDocuments[i]; 


14.3 Quelltext 


"Skeleton.c" 





Make_Menus installiert 
die Menüleiste und trägt 
die Namen der Schreib- 
tischprogramme im 
"Apple'-Menü ein. 


Do_New übernimmt die 
Erzeugung eines neuen 
Dokuments. Diese 
Funktion durchsucht die 
Liste der Dokumente 
nach einem unbenutzten 
Document-struct und 
verwendet dieses zur 
Verwaltung des neuen 
Dokuments. 
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1015: } 

1016: } 

1017: return NULL; 

1018: } 

1019: 

1020: // ---------------------------- 
1021: 

Initialize setzt die 1022: void Initialize (void) 


globalen Variablenauur 1023: { 


ihre Anfangswerteund 102: short i; 
koordiniert den weiteren el 
ae 1026: gQuit = false; 
Initialisierungsprozeß. 1027: gCountDocuments = 0; 

1028: for (i = 0; i < kMaxDocuments; i++) 
1029: gDocuments[i].inUse = false; 
1030: 
1031: Init_ToolBox (); 
1032: Make Menus (); 
1033: Do_New (); 
1034: SetCursor (&qd.arrow); 
1035: } 
1036: 
1037: // === 
1038: 


Das Hauptprogramm 1039: void main (void) 
enthältdie 1040: 


Main-Event-Loop. 101: 1 
1042: Initialize (); 
1043: 
1044: while (!qgQuit) 
1045: { 
1046: qgGotEvent = WaitNextEvent ( 
everyEvent, &gEvent, 15, NULL); 
1047: if (gGotEvent) 
1048: Do Event (); 
1049: } 
1050: } 


14.5 Anmerkungen 


Skeleton bildet eine solide Basis für Ihre ersten Projekte. Dieses 
Rahmenprogramm hat jedoch noch einige Schwächen, die bewußt 
in Kauf genommen wurden, um die Übersichtlichkeit des 


Quelltextes zu wahren. Im Folgenden werden die Schwächen bzw. 
fehlenden Funktionalitäten beschrieben: 


1. Fehlerverwaltung. 

Das Programm überprüft keine Fehlermeldungen bei Dateizu- 
griffen, was zu Datenverlusten führen kann. Wenn der Benutzer 
ein Dokument sichern möchte und das Volume nicht genügend 
Platz bietet, so wird der Benutzer nicht davon informiert, daß 
die Daten nicht gesichert wurden (Save_Document). 

Beim Anlegen von Speicherbereich werden die Ergebniswerte 
der Funktionen nicht auf NULL überprüft, was zu Programm- 
abstürzen in kritischen Situationen führt. Ist nicht genügend 
Speicherplatz vorhanden, um z.B. eine neue Region anzulegen 
(NewRgn), so greift das Programm auf undefinierte Speicher- 
stellen zu. 

Ein "echtes" Macintosh-Programm sollte unbedingt sämtliche 
Fehlermeldungen abfangen und entsprechend reagieren. Dies ist 
insbesondere beim Anlegen von Speicherbereich extrem wichtig, 
da der Macintosh bisher keine Memory-Protection bietet. Das 
bedeutet, daß ein Programm "versehentlich" in den Speicherbereich 
anderer Applikationen oder des Systems schreiben kann, was zu 
einem Systemabsturz führt. 


2. Drucken. 

Jedes Macintosh-Programm sollte drucken können. Die Funk- 
tionalität des Druckens läßt sich mit Hilfe des Printing-Managers 
implementieren, der eine universelle Schnittstelle zu allen Druk- 
kern bietet. Dieser Bereich ist eine gute Aufgabe für erste selb- 
ständige Gehversuche bei der Programmierung des Macintosh 
und wurde daher ausgelassen. 


3. Kopieren und Einsetzen. 

Diese Standardfunktionalität eines jeden Macintosh-Programms 
wird mit Hilfe des Scrap-Managers implementiert. Da die Im- 
plementierung von Kopieren und Einsetzen (je nach Programm) 
unterschiedlich ausfällt, konnte diese Funktionalität nicht in das 
Rahmenprogramm aufgenommen werden. 


14.5 Anmerkungen 





Ein "echtes" Macintosh- 
Programm sollte 
unbedingt sämtliche 
Fehlermeldungen von 
TooIBox- und Betriebs- 
systemroutinen 
überprüfen. 
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4. Widerrufen. 

Jede Aktion, die die Daten eines Dokuments verändert, sollte 
widerrufbar sein. Auch diese Funktionalität ist jenach Programm 
unterschiedlich zu implementieren und konnte daher nicht anhand 
des Rahmenprogramms demonstriert werden. 


Dokumentation MEER 


Dieses Kapitel bildet den Abschluß des Buches. Es gibt zunächst 
einen Überblick über die "Bibel" der Macintosh-Programmierer, 
das "Inside Macintosh". Im ersten Teil des Kapitels wird die 
evolutionäre Entwicklung des Macintosh, seiner Systemsoftware 
und damit auch des "Inside Macintosh" erläutert. Es werden 
Hinweise gegeben, welche Kapitel des sechsbändigen Standard- 
werkes für den weiteren Einstieg in die Macintosh-Programmie- 
rung wichtig sind und welche erst für fortgeschrittene Projekte 
benötigt werden. 

Im zweiten Abschnitt dieses Kapitels wird auf bestimmte Teile 
von "Inside Macintosh" verwiesen, die durch die Weiterent- 
wicklung des Macintosh inzwischen veraltet sind. 

Der dritte Teil gibt einen Überblick über weitere Dokumentation 
bzw. Informationsquellen, die für die professionelle Software- 
entwicklung auf dem Macintosh wichtig sind. 


15.1 "Inside Macintosh" 


Das "Inside Macintosh" ist eine sechsbändige Publikation von 
Apple Computer, die eine Beschreibung der Routinen und Da- 
tenstrukturen von QuickDraw, ToolBox und Betriebssystem 
enthält. Dieses Nachschlagewerk ist die "Bibel" der Macintosh- 
Programmierer und unverzichtbar für die Erstellung einer kom- 
plexeren Applikation. Da ein Macintosh-Programm hauptsäch- 
lich aus einer Aneinanderreihung von ToolBox- bzw. Betriebs- 
systemaufrufen besteht, ist das "Inside Macintosh" der ständige 
Begleiter eines Macintosh-Programmierers. Eine gute Kenntnis 
dieser umfassenden Dokumentation ist sehr wichtig, da sonst 
die Gefahr besteht, "das Rad noch einmal zu erfinden". 387 
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teilt, die jeweils einen Manager beschreiben. Ein solches Kapitel 
ist wiederum in die folgenden Abschnitte unterteilt: 


1. "About the XXX Manager". 

Dieser Teil eines "Inside Macintosh"-Kapitels beschreibt die 
Einsatzgebiete, für die dieser Manager zuständig ist. Es wird ein 
Überblick über die Funktionalität und Datenstrukturen gegeben, 
die dieser Manager zur Verfügung stellt. Dieser Abschnitt sollte 
vor dem Einsatz eines neuen Managers gelesen werden, um einen 
Überblick über die Konzeption und das Einsatzgebiet des Managers 
zu erhalten. 


2. "Using the XXX Manager". 

Dieser Teil eines Kapitel beschreibt den Einsatz des Managers 
und seiner Routinen. Er verdeutlicht die Zusammenhänge zwi- 
schen den wichtigsten Routinen und den zentralen Datenstruk- 
turen. Hier werden die typischen Einsatzgebiete der einzelnen 
Funktionen beschrieben, sowie Querverweise aufandere Manager 
hergestellt. Die in diesem Abschnitt enthaltenen Informationen 
können viele Stunden bei der Fehlersuche ersparen, da sie Richt- 
linien und Beispiele für die Verwendung der Routinen und 
Datenstrukturen geben. Dieser Teil eines Kapitels sollte unbedingt 
gelesen werden, bevor Routinen eines Managers verwendet 
werden. 


3."XXX Manager Routines" 

Dieser Abschnitt eines "Inside Macintosh"-Kapitels beschreibt die 
Routinen, die der Manager zur Verfügung stellt und dient als 
Nachschlagewerk. Die einzelnen Routinen werden (nach ihrer 
Funktionalität) geordnet vorgestellt. 


Die einzelnen Bände der "Inside Macintosh"-Serie bauen aufein- 
ander auf. Die ersten drei Bände bilden den Grundstock, die 
nachfolgenden Bände enthalten Erweiterungen und Neuent- 
wicklungen. Das "Inside Macintosh" spiegelt die evolutionäre 
Entwicklung der Macintosh-Linie wieder. Die einzelnen Bände 
sind im Laufe der Jahre jeweils bei größeren Systemumstellungen 
bzw. Erweiterungen erschienen. Das Erscheinungsdatum der 


15.1 "Inside Macin- 
: tosh" 
einzelnen Bände von "Inside Macintosh" deckt sich mit den Mei- 


lensteinen der Macintosh-Produktlinie: 


"Inside Macintosh" Vol. L, IL, III (1984) 

Die ersten drei Bände stellen die Standarddokumentation dar; 
sie sind sozusagen das "alte Testament". Diese Bände sind zeitgleich 
mit der Einführung des ersten Macintosh (Macintosh 128K) er- 
schienen und beschreiben die wichtigsten Manager des Macin- 
tosh-Gesamtsystems. 


VolumeI: QuickDraw und ToolBox. 
Volume II: Betriebssystem. 
Volume II: Hardware des Macintosh 128K. 


Fast alle Informationen, die in den ersten drei Bänden enthalten 

sind, haben auch heute auf den neuesten Geräten und Betriebs- 

systemversionen uneingeschränkte Gültigkeit. Diese Bände bil- Die ersten drei Bände 
den den Grundstock des Gesamtsystems, auf dem auch die _ bilden den Grundstock 
neuesten Betriebssystemversionen aufbauen. Die Modifikationen des Gesamtwerkes. Die 
und Erweiterungen dieses Grundstocks sind in den folgenden Informationen aus 
Bänden des "Inside Macintosh" dokumentiert. Um den gegen- diesen Bänden sind 
wärtigen Stand eines Managers zu erfahren, muß zunächst im auch heute noch gültig. 
"Inside Macintosh" (I-IID nachgesehen werden und anschließend 

die (eventuellen) Erweiterungen und Modifikationen in den 

nachfolgenden Bänden nachgeschlagen werden. 


"Inside Macintosh" Vol. IV (1986) 

Dieser Band der "Inside Macintosh"-Serie ist parallel zur Einfüh- Vol.IV enthält Informa- 
rung des Macintosh Plus erschienen. Die Erweiterungen, die in tionen über das 
diesem Band enthalten sind, beziehen sich im wesentlichen auf _ hierarchische Datei- 
die Hardware und das Dateisystem, welches auf die hierarchi- system. 

sche Dateiverwaltung umgestellt wurde. 


"Inside Macintosh" Vol. V (1987) 

Dieser Teil des "Inside Macintosh"-Gesamtwerks erschien paral- 
lel zur Einführung des Macintosh II. Er enthält Erweiterungen 
für nahezu jeden Manager der ToolBox. Im wesentlichen bezie- 
hen sich diese Erweiterungen auf die Einführung von Color- 


QuickDraw und auf ToolBox-Manager, die um die Farbfähig- 
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Vol. V enthält im 
wesentlichen die 
Erweiterungen von 
QuickDraw zu Color- 
QuickDraw. 


Vol. VI enthält die 
Neuerungen von 
System 7 


Kompatibilitätslinie des Macintosh dar. Waren bis zu diesem 
Zeitpunkt nahezu alle Erweiterungen auch auf älteren Macin- 
tosh-Rechnern einsatzfähig, so ist Color-QuickDraw bzw. die 
Farbfähigkeit der ToolBox-Manager nur auf Macintosh-Rechnern 
mit 68020, 68030 oder 68040 Prozessor (zur Zeit Macintosh SE/ 
30, Classic II, I, IIx, IIcx, IIci, IIfx, Quadra 700, Quadra 900, 
PowerBook 140, PowerBook 170) vorhanden. 


"Inside Macintosh" Vol. VI (1991) 

Dieser (vorläufig letzte) Band der "Inside Macintosh"-Reihe enthält 
die Neuerungen von System-7. System-7 enthält einige Erweite- 
rungen zu bestehenden Managern, jedoch hauptsächlich komplette 
Neuentwicklungen. Diese sehr umfangreichen Neuentwicklungen 
reichen von virtueller Speicherverwaltung über die Interpro- 
zeßkommunikation bis hin zu völlig neuen Konzepten wie dem 
Help-Manager. Der Inhalt dieses Bandes ist in der Regel für 
Macintosh-Neulinge zu weit gefaßt. Die in diesem umfangrei- 
chen Werk vorgestellten Funktionalitäten sollten zunächst lediglich 
überflogen werden, um einen Überblick zu bekommen. 


15.1.1 "Inside Macintosh" - Wichtige Kapitel 


Das hier vorliegende Buch hat Ihnen eine Einführung in die 
wichtigsten Teile des Macintosh-Gesamtsystems gegeben. Bei der 
Beschreibung der einzelnen Manager wurden jedoch nur die 
essentiellen Routinen und Datenstrukturen beschrieben. Viele 
Manager bieten weitergehende Funktionalitäten, die hier nicht 
beschrieben wurden. Auch existieren einige Manager, die bisher 
nur am Rande angesprochen oder überhaupt nicht erwähnt 
wurden. Diese Erweiterungen wurden absichtlich nicht be- 
schrieben, da das hier vorliegende Buch als Einführung konzipiert 
ist und sich daher auf die wichtigsten Bereiche des Gesamtsystems 
beschränkt. 

Im Folgenden sind eine Reihe von Kapiteln des "Inside Macin- 
tosh"-Gesamtwerkes aufgelistet, die wichtige (weitergehende) 
Informationen enthalten und eventuell vor Beginn eines Projek- 
tes gelesen werden sollten: 


15.1.1 "Inside Maein- 


tosh"- Wichtige Kapitel 





Volume L Kapitel 6: QuickDraw. 
Die wichtigsten Routinen von QuickDraw wurden auch indem Volume I 
hier vorliegenden Buch vorgestellt, QuickDraw bietet jedoch einige 
Abwandlungen von bisher beschriebenen Routinen bzw. nützliche 
Utility-Funktionen, die häufig benötigt werden. Das Kapitel 6 

von "Inside Macintosh" Volume I sollte noch einmal quergelesen 

werden, um einen Überblick über die weitergehenden Routinen 

zu erhalten. 


Volume I, Kapitel 12: TextEdit. 

Dieses Kapitel beschreibt den TextEdit-Manager, welcher die 
Texteingabefelder in Dialogen verwaltet. Die Routinen und Da- 
tenstrukturen dieses Managers können auch für eine einfache 
Textverarbeitung verwendet werden. TextEdit wird in vielen 
Projekten verwendet, da es eine hohe Integration bietet und die 
Texteingabe standardisiert. Wenn Sie in Ihrem Projekt Textein- 
gabefelder intensiv nutzen wollen, so sollten Sie dieses Kapitel 
lesen. 


Volume I Kapitel 15: Scrap-Manager. 

In diesem Kapitel wird der Teil der ToolBox beschrieben, welcher 
sich mit der Implementierung von "Kopieren und Einsetzen" 
beschäftigt. Da diese Funktionalität in nahezu jeder Macintosh- 
Applikation zu finden ist, gehört der Scrap-Manager zur Pflicht- 
lektüre. 


Volume II, Kapitel 4: File-Manager. Volume Il 
Dieses Kapitel des "Inside Macintosh" enthält, neben den bisher 
beschriebenen Routinen des File-Managers, weitere Möglichkei- 

ten, die für bestimmte Projekte sehr interessant sein können (z.B. 
asynchroner Dateizugriff). Dieses Kapitel gehört nicht unbedingt 

zur Pflichtlektüre. Wenn Sie jedoch intensiv mit dem Dateisystem 

arbeiten wollen, so sollten Sie dieses Kapitel des "Inside Macin- 

tosh" lesen. 


Volume I, Kapitel 5: Printing-Manager. 
Hier wird die Technik der Druckeransteuerung auf dem Macin- 
tosh beschrieben. Der Printing-Manager ist recht einfach zu be- 


nutzen, da eine universelle Schnittstelle zu allen Druckern existiert. 
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Volume IV 


Volume V 


des Druckens in fast allen Macintosh-Applikationen zu finden 
ist. 


Volume II, Kapitel 9: The Serial Drivers. 

Wenn Ihr Projekt die Ansteuerung serieller Geräte beinhaltet, so 
wird dies über diese Treiber geschehen. Wenn Sie im Bereich 
DFÜ arbeiten, so sollten Sie die Communication-ToolBox ver- 
wenden, welche in einer Zusatzdokumentation beschrieben wird. 
Die Communication-ToolBox beinhaltet Standardisierungen für 
die Datenfernübertragung in bezug auf Protokolle und Datei- 
transfer. 


Volume II, Kapitel 10: AppleTalk. 

Wenn Sie im Bereich Netzkommunikation arbeiten wollen, so 
sollten Sie dieses Kapitel lesen, da es die Beschreibung des 
Hardware-unabhängigen Netzprotokolls AppleTalk enthält. 


Volume IV, Kapitel 19: File-Manager. 

Dieses Kapitel beschreibt Erweiterungen des File-Managers, die 
für die Implementierung des hierarchischen Dateisystems vor- 
genommen wurden. Es ist damit eine Fortsetzung von Volume 
Il, Kapitel 4. 


Volume IV, Kapitel 30: List-Manager. 

Der List-Manager bietet sehr flexible Möglichkeiten, Listen oder 
Tabellen zu erstellen. List-Manager-Listen standardisieren die 
Benutzerschnittstelle in bezug auf die Darstellung und Selektion 
einzelner Zellen und bilden einen wichtigen Bestandteil vieler 
Macintosh-Programme. Wenn Sie dem Benutzer beispielsweise 
die Möglichkeit geben wollen, in einem Dialog einen Namen aus 
einer Liste auszuwählen, so sollten Sie den List-Manager ver- 
wenden. Dieses Kapitel gehört für die meisten Programmierer 
zur Pflichtlektüre. 


Volume V, Kapitel 4: Color-QuickDraw. 
Dieses Kapitel beinhaltet die wesentlichen Erweiterungen von 
QuickDraw zu Color-QuickDraw. Wenn in Ihrem Projekt Farbe 


15.1.1 "Inside Macin- 


tosh'- Wichtige Kapitel 





eingesetzt werden soll, so sollten Sie dieses Kapitel aufmerksam 
studieren. 


Volume V, Kapitel 7: Palette-Manager. 

Wenn ihr Projekt intensiv die Farbfähigkeiten der neueren 
Macintosh-Rechner nutzen soll (Color-QuickDraw), so sollte dieser 
Manager verwendet werden, um eine einheitliche Farbumgebung 
für das Programm zu schaffen. Der Palette-Manager ermöglicht 
die automatische Modifikation der Color-LookUp-Table (CLUT), 
welche die Farbumgebung (die Farben, die zur Auswahl stehen) 
definiert. 


Volume V, Kapitel 13: Menu-Manager. 

Hier werden einige wichtige Erweiterungen des Menu-Mana- 
gers vorgestellt, die für die meisten Projekte interessant sind. Zu 
diesen Erweiterungen zählen beispielsweise die hierarchischen 
und die PopUp-Menüs. Da die Erweiterungen in dem vorliegenden 
Buch nicht beschrieben sind, sollten Sie dieses Kapitel des "Inside 
Macintosh" lesen, um sämtliche Funktionalitäten des Menu-Ma- 
nagers nutzen zu können. 


Volume VI, Kapitel 1-3. Volume VI 
Diese Kapitel der System-7-Dokumentation beinhalten eine Ein- 

führung in die neuen Möglichkeiten von System 7. Sie geben 

weiterhin Kompatibilitätsrichtlinien für die Erstellung System- 
7-kompatibler Programme. Diese Kapitel sollten gelesen werden, 

um für den späteren Einsatz der System-7-Fähigkeiten vorbereitet 

zu sein. 


Volume VI, Kapitel 6: AppleEvent-Manager. 

Dieses Kapitel beschreibt die obere Schicht der Interprozeßkom- 
munikation unter System-7. Diese Kommunikation geschieht über 
eine Erweiterung der Main-Event-Loop und stellt eine moderne 
Form der Interprozeßkommunikation dar. Dieses Kapitel ist in- 
teressant, wenn mehrere Programme miteinander kommunizieren 
bzw. einander steuern sollen. 
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Dieses Kapitel enthält wesentliche Erweiterungen für die Netz- 
kommunikation, wie z.B. ADSP (AppleTalk Data Stream Protocol), 
und ist eine Erweiterung zu Volume II, Kapitel 10. 


15.1.2 "Inside Macintosh" - Problematische Kapitel 


In diesem Abschnitt werden die Kapitel des "Inside Macintosh" 
aufgelistet, deren Inhalt mit Vorsicht zu genießen ist, da an den 
Bereichen, die sie beschreiben, starke Veränderungen vorge- 
nommen worden sind. Diese Kapitel beinhalten Informationen, 
die nur in Verbindung mit späteren Ergänzungen dem heutigen 
Stand entsprechen. 


Volume I, Kapitel 3: Memory Management. 

Dieses Kapitel beschreibt die Konzepte der Macintosh-Speicher- 
verwaltung, die seit der Einführung des Macintosh 128K (Volume 
I-IID stark verändert worden ist. Zwar stimmen die Informatio- 
nen dieses Kapitel im Prinzip immer noch, Apple hat jedoch einige 
einschneidende Weiterentwicklungen in diesem wichtigen Teil 
des Macintosh-Gesamtsystems vorgenommen. Da die Doku- 
mentation von Volume I immer noch auf dem Stand von 1984 
ist, können Fehleinschätzungen aus der Lektüre dieses Kapitels 
entstehen. 


Volume I, Kapitel 7: Font-Manager. 

Der Font-Manager wurde mit der Einführung des Macintosh Plus 
(Volume IV) stark modifiziert. Sollte Ihr Projekt starken Gebrauch 
von Schriften machen (z.B. eigene Laufweitenberechnungen von 
Texten), so sollte unbedingt Volume IV, Kapitel 5 sowie Volume 
VI, Kapitel 12 hinzugezogen werden. 


Volume II Kapitel 1: Memory-Manager. 

Obwohl die Routinen des Memory-Managers heute genauso 
funktionieren, wie in diesem Kapitel beschrieben, haben sich die 
Datenstrukturen (Block-Header und Trailer) stark verändert. 
Die Informationen über diese Datenstrukturen sind teilweise ungültig! 


Die in dem vorliegenden Buch vorgestellten Routinen und 
Datenstrukturen des Memory-Managers entsprechen dem neu- 
esten Stand. Sollten dennoch weitergehende Informationen 
benötigt werden, so sollten die Kapitel der "Inside Macintosh"- 
Bände IV und VI zum Thema Memory-Management gelesen 
werden, da sie auf die Veränderungen des Memory-Managements 
hinweisen bzw. die neuesten Techniken beschreiben. 


Volume II, Kapitel 7: Disk-Driver. 

Dieses Kapitel enthält Hardware-abhängige Informationen über 
das Diskettenformat, die teilweise ungültig sind bzw. stark er- 
weitert wurden. 


15.2 Weitere Informationsquellen 


Es existieren (neben dem "Inside Macintosh") viele Zusatz- bzw. 
Spezialdokumentationen, die Informationen über Hardware oder 
spezielle Systemsoftwareteile enthält. Diese Dokumentationen 
enthalten beispielsweise Hardware-Informationen über das De- 
sign einer NuBus-Karte oder Dokumentation über zusätzliche 
Betriebssystemteile (wie z.B. der Communication-ToolBox). 
Die zusätzlichen Dokumentationen können von registrierten 
Apple-Entwicklern direkt bei Apple Computer bestellt werden. 
Apple bietet ein Entwicklerprogramm an, das aus Telefon-Ser- 
vice, Schulungen, Informationsveranstaltungen und einem re- 
gelmäßigen Mailing besteht. In diesem Mailing ist u.a. eine CD- 
ROM (Developer-CD) enthalten, die von der US-Entwicklerunt- 
erstützung produziert wird. Diese Developer-CD-Serie enthält 
eine elektronische Version der "Inside Macintosh"-Bücher, sowie 
viele Beispiel-Programme (mit Quelltext), die sich mit den ver- 
schiedensten Themenbereichen der ToolBox beschäftigen und 
ständig aktualisiert werden. Weiterhin ist auf diesen CDs eine 
elektronische Version der sogenannten "Technotes" vorhanden. 
Die Technotes enthalten wichtige Tips und Tricks, die bei der 
Programmierung des Macintosh beachtet werden sollten. Diese 
Technotes werden regelmäßig aktualisiert und erweitert, so daß 
sie eine wichtige Informationsquelle darstellen. 


15.2 Weitere 


nielguzulejgsieistzlleig 





Die Developer-CDs 
stellen eine wichtige 
Informationsquelle dar. 


Die Technotes enthalten 
wichtige Tips und 
weisen auf Probleme 
bzw. deren Lösung hin. 


395 


Kapitel 15 


Dokumentation 





396 


Eine weitere Möglichkeit, Dokumentation bzw. neue Informa- 
tionen zu bekommen, besteht durch die Verwendung von 
AppleLink. AppleLink ist eine Art weltweiter "Mailbox", in der 
ein Bereich für Entwickler reserviert ist. In diesem Bereich exi- 
stieren "Schwarze Bretter", in denen Diskussionen über neue 
Entwicklungen und Problemlösungen geführt werden. Apple 
versorgt die Entwickler über diesen elektronischen Kanal stets 
mit den neuesten Informationen über die Entwicklung neuer 
ToolBox- oder Betriebssystemteile und stellt einige weitergehende 
Informationen zur Verfügung. 


Schlußwort BEEEEIE 


Durch die Lektüre dieses Buches haben Sie sich selbst einen 
Grundstein für die Programmierung des Macintosh gelegt. Es 
ist der erste Schritt zur Entwicklung einer professionellen Mac- 
intosh-Applikation. Der Weg zu einem Macintosh-Profi steht Ihnen 
jetzt offen - auch wenn dazu noch etwas Erfahrung und einige 
Vokabeln (Manager) fehlen. 

Im Laufe der nächsten Zeit sollten Sie sich intensiv mit der Mac- 
intosh-Programmierung befassen, da die hier vorgestellten In- 
formationen nur zu echtem Wissen werden, wenn sie angewen- 
det werden. 

Zunächst sollten Sie die im vorangegangenen Kapitel vorgestell- 
ten Abschnitte des "Inside Macintosh" überfliegen, um sich mit 
Ihrem neuen Begleiter vertraut zu machen. Wenn Sie sich für die 
MPW-Shell als Entwicklerwerkzeug entscheiden, so beschäfti- 
gen Sie sich nicht allzulange mit der Dokumentation der Ent- 
wicklungsumgebung, sondern starten Sie möglichst bald die ersten 
Experimente. 

Bevor dann schließlich mit dem ersten ernsthaften Projekt begonnen 
wird, sollten Sie eine intensive Planungsphase voranstellen. 
Unüberlegte Konstruktionen können sich bei der Macintosh- 
Programmierung fatal auswirken. Insbesondere sollten Sie die 
Oberfläche des Programms grob definiert haben, bevor Sie die 
erste Zeile inC programmieren - es lohnt sich auch, die Oberfläche 
mit potentiellen Benutzern (erfahrenen Macintosh-Benutzern) zu 
besprechen, da so Fehlentwicklungen vorgebeugt werden kann. 


Viel Spaß und Erfolg bei den ersten Projekten! 


Carsten Brinkschulte 
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